Tabs vs Spaces (yes, again!)

PIG DISGUSTING

{
    int a    = 3;
    int ab    = 4;
    // ...
}


{
   int a  = 3;
   int ab = 4;
}

BEAUTIFUL AND NICE

{
    int a  = 3;
    int ab = 4;
}

Style 1 (all tabs) will look fucked up vertical alignment with different tab widths. Style 2 (all spaces) will look weird to those used to different tab widths. Style 3 (tabs to indent, spaces to align), on the other hand, is made of epic win because it allows one to change the tab width without losing the nice vertical alignment, and those who really like all spaces can easily have their editor auto-convert tabs to spaces.

Style 3 > Style 2 > Style 1. If you use Style 1, you're an asshole.

gtfo

Ha, fuck. Firefox shows tabs with a width of 8, but /prog/ displays them with a width of four. More proof of how PIG DISGUSTING it is to use tabs to align.

Using tabs to indent and assuming you can just change the tab width COMPLETELY ignores the right margin. Switching from code that assumes 4 spaces per tab to normal 8-space tabs results in a lot of pain-in-the-ass horizontal scrolling and/or word wrap, depending on editor.

>>3
You mean, how disgusting it is to s/\t/    /g right?
If only shiichan left the tab as is, you'd be able to configure your firefox to show it as you want.

>>4
Yeah, no shit. Makes you wonder what the point of tabs are.

I use spaces only because of faggots like >>1 who think they have the right to display my code in a way I did not intend.

I don't indent. I'm not being forced, so why do it?

>>8
Most of use have no choice in the matter. Our editors do it automatically.

>>5
Code is supposed to be readable. For that to be so, it needs to remain in the appearance it was when the original creator made it. Fucking with that is asking for controversy for little gain. “OH, I LIKE 4-SPACE INDENTATION”; “NO I LIKE 8-SPACES”. You losers are missing the point: if you're writing code in a language, your style should be consistent with that of the language, and that style should be specified and unambiguous. What's the point in allowing style freedom? (1) You'll have trouble reading code written by someone else or it will cause controversy; (2) if you _don't_ have trouble reading code in a different style, why are people even bothering with different styles? One specific style cannot be more superior than another. If you've decided 2-space indentation is great, that's fine, but it doesn't matter if nobody else uses it. This is why Python is an enlightened language; people who choose to use it accept the style specifications and use it happily. I hear they are now specifying that only one be allowed.

The
foo {
}
vs.
foo
{

}
argument is so completely inane. If you're going to indent your code, why are curly braces even necessary? This is why Haskell is superior.

In the end this boils down to giving people freedom where it isn't constructive. You don't give people three ways to declare a function. Why should you give them any more ways than _one_ to layout their code?

>>8
I don't indent.
Leave.

I don't use any whitespace, except the minimal required by the language:

{int a=3,ab=4;}

>>12
Missed the point.

I would use the taps+spaces option, but ARGHH MIXING, so I stick with spaces.

int a = 3, ab = 4;
or GTFO

The problem is that we still store source code as plain text.

If we used binary formats containing some sort of parse tree, everyone could change the layout to whatever they liked. Plus, syntax highlighting and code completion would be easier to implement, and compiling would be faster because you wouldn't have to do text parsing first.

>>16
That's true. We should use some sort of ISO 8824 based format to store it, for maximum compatibility amongst disparate systems.

>>17
No - XML with stylesheets.

>>18
No... Just no...

Tabs are obviously superior because in almost any text editer you can define how long they are.  Plus you're not pressing space 8 times for each line of code.

>>18

<?xml version="1.0" ?>
<program language="C">
    <line number="1" text="#include &lt;stdio.h&gt;" />
    <line number="2" text="" />
    <line number="3" text="int main(int argc, char *argv)" />
    <line number="4" text="{" />
    <line number="5" text="&tab;printf(&quot;Hello world!\n&quot;);" />
    <line number="6" text="&tab;return 0;" />
    <line number="7" text="}" />
</program>

>>20
I think I'm gona puke.  That will just bump the file size of code 20 times over.

>>21
You obviously don't understand the benefits of a universal data exchange format such as XML.

>>1
You're not supposed to align up assignment statements, idiot.
Some poor guy will create a new variable abc, or fix the 4 to a 14, and then feel obligated to run around and realign it so it looks all orderly again. That's completely wasted effort, and it looks better to just consistently whitespace each statement by itself.

>>20
How about this?


<?xml version="1.0" ?>
<program language="C">
    <include type="system">stdio.h</include>
    <function type="int" name="main">
        <argument type="int" name="argc" />
        <argument type="char **" name="argv" />
        <code>
            <call function="printf">
                <argument type="char *">&quot;Hello, world!\n&quot</argument>
            </call>
            <return>0</return>
        </code>
    </function>
</program>

>>24
...
<argument>
  <type>
    <pointer>
      <pointer>
        <basetype type="char" />
      </pointer>
    </pointer>
  </type>
  <name>argv</name>
</argument>
 ...
<return>
  <literal>
    <type>
      <basetype type="int" />
    </type>
    <value>0</value>
  </literal>
</return>

>>25
I was just thinking about something like that. Then editors could provide type-checking! But your idea is a tad too verbose.


<argument name="argv">
  <type pointers="2">char</type>
</argument>
 ...
<return>
  <literal value="0">
    <type>int</type>
  </literal>
</return>

Hey, /prog/, maybe we should get to writing a standard for storing C code as XML. We'd have to write a plugin for some editor too (probably emacs, cause then we'd just need to distribute a .el file.)

And if the source is invalid, how will it be stored? And how would it handle macros (which could expand differently, and may or may not be defined depending on what is included, the environment, the compiler, and other things...)?

>>24
Generalize "include" to "directive" instead, I think.

>>27
Invalid files probably couldn't be stored.


<define name="MAX">
    <argument name="a" />
    <argument name="b" />
    <code>(((a) > (b)) ? (a) : (b))</code>
<define>

And why generalize "include"? This standard should be more user-friendly than program-friendly.

Current work-in-progress idea.


<?xml version="1.0" ?>
<!-- An idea on how to portably store source files with XML. -->
<!-- By Anonymous. -->
<file language="C">
    <!-- These are the recommended preferences. -->
    <!-- These would normally be configured per-user, but an author could -->
    <!-- ask to override these with ones specified per-file, like this. -->
    <preferences>
        <!-- Fairly self-explanatory names. -->
        <column-limit>80</column-limit>
        <indent-type>spaces</indent-type>
        <indent-size>4</indent-size>
        <indent-style>K&R</indent-style>
    </preferences>

    <!-- "system" means angle brackets. "local" means quotes. -->
    <include type="system">stdio.h</include>

    <!-- force a newline. -->
    <newline />

    <!-- non-function macros would still have <code>, but not <argument>s. -->
    <define name="MAX">
        <argument name="a" />
        <argument name="b" />
        <code>(((a) > (b)) ? (a) : (b))</code>
    <define>

    <!-- start a function definition. -->
    <function type="int" name="main">
        <!-- arguments expected by the function. -->
        <argument type="int" name="argc" />
        <argument type="char **" name="argv" />
        <code>
            <!-- start a function call -->
            <call function="printf">
                <!-- arguments to pass to the function. -->
                <argument>
                    <literal type="char *">Hello, world!\n</literal>
                </argument>
            </call>
            <return><literal type="int">0</literal></return>
        </code>
    </function>
</program>

I said binary formats, assholes.

>>28
OK, but let's say you have a macro not stored in your XML source file which could be defined as
#define X(n) const int n
#define X(n) some_function or any number of things. At the point of instantiation:
X(x) (5); how is it handled? Is it an initializer list (the first) or a function call (the second)? Surely the parser needs to expand it to understand what the following code actually is?

Even #define Z enum could give it troubles.

>>26
emacs
XML
It's too bad Emacs doesn't already have some kind of format suitable for the storage and manipulation of hierarchical structures, and it is additionally too bad that this format that doesn't exist can't be compiled and stored in a binary file.

You could certainly do it with a language other than Sepples. C and Sepples macros are terrible. LISP macros are of course much better.

>>32
Emacs doesn't have an XML library?  Who would have known.  Also, XML does exist.

>>34
What's that whoooosh sound?

I lol'd at you guys taking my posts >>18 and >>20 seriously.

>>35
Is it you running as fast as you can back to /.? I hope it is.

>>36
You have an interesting definition of ``seriously''

We also haven't made the stylesheets yet!

>>31

<define name="X">
    <argument name="n">
    <code>const int n</code>
</define>
<!-- ... -->
<assignment>
    <left>
        <call function="X">
            <argument>myvar</argument>
        </call>
    </left>
    <right>
        <literal type="int">5</literal>
    </right>
</assignment>

>>32
I suggested emacs because it would be easier to write and distribute a plugin for it. I know that S-Expressions and XML are similar, but XML would be more ENTERPRISE and better understood/supported by other editors.

>>38
Let's say the definition of X is in a different source file. Are you going to load that file too? What if you separate the files?