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.

>>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.