3 ms·

> The whole concept of every coder using his or her favorite tab size for the same file is completely, utterly moronic. > If the coding convention calls for ha

> The whole concept of every coder using his or her favorite tab size for the same file is completely, utterly moronic. > If the coding convention calls for hard tabs, it must firmly establish their size and everyone must use that size. Letting coders and readers of code choose their own tab size isn't moronic, and you don't need to firmly establish the tab size. That's only an issue if you use column alignment after the initial indent. Column alignment is not a requirement in any of the programming languages most of us work in. It's just a stylistic choice, and it causes many problems including the one you describe. If you stop using column alignment, it doesn't matter what tab size someone uses when they view or edit the code. It doesn't even matter if they use a proportional font! Take your example: if (foo) /* comment */ bar(); /* comment */ ^ this is a hard tab stop and rewrite it without alignment: // Plenty of room for a longer comment here if( foo ) bar(); Or if you really need a comment for each line: // Plenty of room for a longer comment here if( foo ) { // And room for a long comment here too bar(); } Either way, you're no longer dependent on the tab size, and not dependent on monospaced fonts either. The code is consistently formatted in any font, even if you set your tabs to display as something odd like five spaces: // Plenty of room for a longer comment here if( foo ) { // And room for a long comment here too bar(); } Here's a more detailed discussion of the problems that column alignment causes and the benefits of giving it up: https://news.ycombinator.com/item?id=10206860 https://news.ycombinator.com/item?id=10206860

kazinator 11y ago
> Letting coders and readers of code choose their own tab size isn't moronic I don't like 32 bit IP addresses or 128 bits. I think I will make them 48 bits on my machine. My personal preference beats conventions and standards; that's why I went into computing in the first place! Why stop at tabs? Every developer should choose their own character encoding. Networking guy Ardeshir is from Iran; let him code from right to left. And let Shigeru can use SHIFT-JIS identifiers for functions, in the middle of UTF-8 source files. Conformance was yesterday; today, personal preference is king!
amag 11y ago
Yeah, I hate comments at the end of a line of code. No good can ever come from having a comment on the same line as code, it only encourages completely meaningless comments like: int a = 0; /* assign 0 to a */ a += 5; /* add 5 to a */ Until you realize that you were really meant to add 6 to a and change the code and not the comment. Comments should be written on their own line(s) and only to explain the intention or warn against uninformed changes (or both): // WARNING! There be dragons here. It *may* look like we're reading // uninitialized memory here but it's all part of a greater plan, // the plan to get some good entropy into the random pool. So don't // remove the reads you don't understand, even if lint tells you // they're bad or you'll severely limit the entropy of all users // private keys from now on.

kazinator 11y ago

> Letting coders and readers of code choose their own tab size isn't moronic I don't like 32 bit IP addresses or 128 bits. I think I will make them 48 bits on my machine. My personal preference beats conventions and standards; that's why I went into computing in the first place! Why stop at tabs? Every developer should choose their own character encoding. Networking guy Ardeshir is from Iran; let him code from right to left. And let Shigeru can use SHIFT-JIS identifiers for functions, in the middle of UTF-8 source files. Conformance was yesterday; today, personal preference is king!

amag 11y ago

Yeah, I hate comments at the end of a line of code. No good can ever come from having a comment on the same line as code, it only encourages completely meaningless comments like: int a = 0; /* assign 0 to a */ a += 5; /* add 5 to a */ Until you realize that you were really meant to add 6 to a and change the code and not the comment. Comments should be written on their own line(s) and only to explain the intention or warn against uninformed changes (or both): // WARNING! There be dragons here. It *may* look like we're reading // uninitialized memory here but it's all part of a greater plan, // the plan to get some good entropy into the random pool. So don't // remove the reads you don't understand, even if lint tells you // they're bad or you'll severely limit the entropy of all users // private keys from now on.