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?

>>38 not to mention, you got it wrong yourself: it's not an assignment, it's either a declaration with initializer or a function call.


int main(void)
{
    int a = 3, ab = 4;
    printf("This is as it should be. Do not get hung up on style rules. Write the program first.\n");
    printf("you, you DOUBLE NIGGER.\n");
    return 0;
}

>>41
C doesn't have initializers like C++ does, I think.


int a(4); // valid C++, invalid C

C++ grammar is so complex that even attempting to express it as XML would be insane.

>>43
You mean that it has many special cases and is baroque overall. Not particularly complex.

>>43
You suck.

int a = 4; is perfectly valid.

>>45
I never said that it was invalid. Read the fucking post. I said that "int a(4);" is valid C++, but not valid C.

>>46
Oh.
Uhm.. YHBT LOL

>>46
In your opinion, would you say you have been
 ◯ Not trolled
 ◯ Trolled slightly
 ◯ Moderately trolled
 ⦿ Trolled strongly
 ◯ Thoroughly Tolled

>>48
E. Thoroughly Trolled, but in good spirits about it :)

>>26
int a;
int b;

while(a<5) {
<tab="4">
a++;
b+=5;
</tab>
}
cout << a << "  " << b <<

Who's writing the Eclipse plugin?

You're all fucking faggots or trolls.  Fuck binary/XML sauce code proposals.

int a=3;
int b=4;
int main(int argc, char **argv) {
 int d,e;
 while(1)
  printf("NIGGERS!\n");
 }
}
ONE SPACE IS ALL YOU NEED FOR INDENTATION. ANYONE WHO CAN'T SEE ONE SPACE ON A MONOSPACED FONT IS BLIND.

>>53
i read 'blind' as 'bald' at first

>>30
How about Binary XML?

>>51
I'll start. Here's the MANIFEST.MF
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Enterprise Binary XML C Sauce Parse Tree Plug-in
Bundle-SymbolicName: niggers
Bundle-Version: 1.0.0
Bundle-Activator: niggers.Activator
Require-Bundle: org.eclipse.ui,
 org.eclipse.core.runtime
Bundle-ActivationPolicy: lazy
Now someone do the build.properties.

>>55
A believe that an official draft of binary XML is in the works, but there are already some other libraries that provide what has been called a binary XML.

Check out http://en.wikipedia.org/wiki/Extensible_Binary_Meta_Language

I'd just like to express my opinion once again that this idea is thoroughly retarded.

wolves

hax my anus
hax    my    anus
hax       my        anus

>>58
You are wrong. It's great. It could be very useful when used together with version control and teams of programmers where each one of them prefers a different code style.

No more tabs vs. spaces, because there will be none actually needed to store the code (only exception to this I can think of are comments). Also, automatic code checking and other nice things will be much easier to do with this.

In other words: FUCK YOU.

Tabs win.  1 ascii character vs 8.

>>61
It's great, except for:
 • the unaddressed problems which have been mentioned so far (viz. expansion of macros and the complexity of languages like Sepples)
 • it adds yet more complexity to the editor
 • it is not exactly difficult to read different coding styles anyway
 • adding a new format when tools are already written to work with existing formats is just going to cause problems
 • what if you want to deviate from the coding style? Is that allowed, or does the editor know better than the coder himself? If someone does do so, what does it look like to someone whose editor lays out the code differently?
 • it has yet to be explained how non-standard structures such as __attribute__ and __dllexport will be handled. What about Qt signals and slots? What happens if one editor writes out XML (or EBML, or whatever) that another editor doesn't understand? I'm guessing there will be some sort of construct for inserting literal text.
 • it's going to be a royal pain in the arse to edit without a compatible editor, unlike standard text files. This just puts an additional barrier of entry to someone working on a project using this format.
 • automatic code checking is already a fairly well-solved problem (for example dehydra, implemented as a GCC plugin, works pretty well even for codebases like mozilla's).
 • things like intellisense/code insight already work fairly well, and this format will not help. Tools like intellisense in particular have problems understanding C++ template metaprogramming¹ (understandably), and getting the correct definition of macros/typedefs when it depends on include paths, preprocessor arguments and TMP.
 • tabs and spaces could be handled without faggotry like this.

Of course, if you really think it's worth it, by all means waste your time. But I just don't think you're going to convince anyone that this is worth the extra effort.

HIBT?
¹hereinafter TMP

One word: s-expressions.

python haz forced tabs lawl xD

expansion of macros
Only a problem with shitty macros which are not independent tree branches.

and the complexity of languages like Sepples
If it has a grammar, I don't see the problem.

what if you want to deviate from the coding style?
Since you would have full control over the style, you should change the style rules, instead of trying to work around them.

it has yet to be explained how non-standard
If they follow a grammar, I don't see the problem.

What happens if one editor writes out XML (or EBML, or whatever) that another editor doesn't understand? it's going to be a royal pain in the arse to edit without a compatible editor
You would simply need a parse-tree-format to text convertor (with options for setting style rules), and a text to parse-tree-format convertor.

[..whining omitted..]

>>66
If it has a grammar, I don't see the problem.
Therein lies the problem.

>>66
Only a problem with shitty macros which are not independent tree branches.
So you admit that it is a problem? Shitty code exists, you can't ignore it. Maybe you would just have in the XML:
<macro-call name="SOME_GAY_MACRO">
  <arg>x</arg>
  <arg>2</arg>
</macro-call> but of course your editor would have to know that it's a macro, not a function call. Do you intend for your editor to preprocess your code (with the correct include directories of course)?

If it has a grammar, I don't see the problem.
Extensions obviously aren't included in the C++ grammar. GCC uses the __attribute__(()) syntax, VC uses the __declspec (and other keywords), and the extensions often go in arbitrary places. If you fail to parse these as keywords, you'll hit problems.

How do you parse:
X(Y) A B();
 or
struct A {
} C D;
 or
_Check_return_wat_ _CRTIMP_ALTERNATIVE errno_t __cdecl wcscat_s(_Inout_z_cap_(_SizeInWords) wchar_t * _Dst, _In_ rsize_t _SizeInWords, _In_z_ const wchar_t * _Src);

_Check_return_ static __inline size_t __CRTDECL wcsnlen_s(_In_z_ const wchar_t * _Src, _In_ size_t _MaxCount)
{
    return (_Src == NULL) ? 0 : wcsnlen(_Src, _MaxCount);
}
without knowing what X, Y, and C mean? (C is __attribute((packed)), X is __declspec, Y is dllexport). Considering vendors can easily define new versions of these if they like, do you just ignore them?

It sounds like you've now gone from an editor that will merely show incorrect colours/formatting when it doesn't understand the code to an editor that fucks up the code when it doesn't understand it.

Additionally it sounds like (in C++ at least) this format would be useful only for simple operations such as transforming indentation or in quite limited conditions in which the editor can understand all of the code.

Since you would have full control over the style, you should change the style rules, instead of trying to work around them.
You can change the rules, but what if you want to work around them just once? Perhaps these two items really would look better when lined up. Do you hack the rules so that in this specific case, it works? Sounds silly.

You would simply need a parse-tree-format to text convertor (with options for setting style rules), and a text to parse-tree-format convertor.
So I have to fanny about converting between this format and plain text so that I can edit a file? How exactly does this format help again? If this codebase has thousands of files it's going to suck, even if it's automated. Not worth it for the tiny gains you'll get.

ITT we rewrite indent, ENTERPRISE STYLE

i had to think about tabs vs spaces again recently.

if your source contains tabs, the mantra is: tabs for indention, spaces for alignment. if you stick to that, code looks 'right' at whatever width people choose to interpret a tab to indicate.

a lot of the 'arguments' i heard against using tabs in source code boiled down to that people could not be trusted to do this correctly. that's probably true, because it's a little hard to see advanced whitespace errors like tab after first nontab on a line.

or, some people remember that historically, tab was for aligning typewriter crap or going to the next mod 8 = 0 cursor position on a dumb terminal and want to stick to that. i really don't understand those people. to me, tab is just a convenient character with no visible representation that means, in the context of source code, that i'm in a new scope/block.

so to me, tabs seem technically superior. but for various reasons, they're not convenient to actually use. people fuss at you about it, they're hard to paste, blah blah. for various reasons, we decided to switch to all spaces and ban tabs. in vim, we use

set tabstop=8 shiftwidth=4 expandtab
and stuff like
highlight WSError ctermbg=red guibg=red
autocmd FileType c,java,ruby,txt,vim,xml match WSError /\s\+$\|\t/
to show us the whitespace errors.

i think maybe the root of the problem is that we insist on editing source as if it was the same type of thing as a book manuscript when we should really edit and store them as trees. in a way, all source code now is cluttered with crap to help parsers that aren't especially meaningful or helpful to humans. code can and should look however you want, including having keywords in your language, if you want. but i don't even see anybody thinking about that or working on that, so it'll be a while. for now, all spaces. :(

I  h a x e d  m y  a n u s  a n d  m y  a n u s  f e e l s  k i n d  o f  h a x e d  n o w :(

you have really clarified this discussion. also, haxing/blueboxing anuses goes back to at least 1997; see haxor bros magazine.

>>30
Gzipped xml, then?

XSLT pretty much achieves the level of retardation and verboseness  you're trying to reach, btw. And it's a pain to read.

>>69
indent needs rewriting anyway. It fucks with your code. Can't be trusted.

I  h a x e d  m y  a n u s  a n d  m y  a n u s  f e e l s  k i n d  o f  h a x e d  n o w :(

    hax my anus.
    I mean, what a meme dude. So deep, so many ways to fit in context, so modifiable, loved by everyone the very moment it was posted, god dammit it blows my fucking mind.

    Seriously guys, HAX MY ANUS. fucking hilarious.