6 ms·

> Align everything you can in code Yes. Makes code easier to read and makes it easier to refactor if you use an editor with column select/multi-line caret.

by T-R 16y ago

barrkel 16y ago
I personally detest people who do this, outside of things like tables (i.e. structured constant initializers) and comments on type definitions. If there's a high degree of regularity in the source that you're trying to expose, there's probably a better way of doing it - extracting out common variables, using a table lookup, adopting acronym conventions for regular parts along any given axis which have the same length, so that the code naturally lines up without ugly random rivers of space down the middle. Unsigned types, on the other hand, are just evil. Way too many people use an unsigned type because they think it represents an invariant that this value will never be negative, that it has some kind of documentation or safety aspect, but that's just wrong. Unsigned types don't act according to the intuitions of most average programmers, and things as simple as for-loops are incredibly easy to get wrong with them (e.g. think about the most common idiom for iterating backwards in C derivatives). If I had my druthers, mixing signed and unsigned ought to expand the expression to the next larger signed type that can represent the range of both (and error out if there is none), and there ought to be separate subtraction / decrement operators specifically for unsigned types. 'u += -2' where u is unsigned would be a type error - assigning a signed value to an unsigned location.
- Stormbringer 16y ago
  Sometimes I arrange my variable declarations so that they make a picture of something in profile... ... don't hate me because I'm beautiful ... :D ---- On a more serious note, something I have noticed working on large projects with other programmers, is that if each programmer has their own distinctive style and conventions, then you can tell straight away by looking at it who wrote it, and more importantly who modified it. Thus if Billy (who is an idiot) modified something written by Sheila (who is like unto the goddess of inspired poetry in wisdom and understanding), and the whole is broken, you can pretty much bet that it is Billy's modification that has broken it, and you can spot his bits straight away, this makes debugging a lot easier. I think this is one of the more unfortunate side-effects of things like checkstyle and other forms of overly restrictive style enforcement. The more we sand-paper everybody back to the same (low) level of code appearance, the more information is lost for what I like to call "forensic debugging".
  - barrkel 16y ago
    I strongly agree with this as well - however, when I need to overhaul a huge portion of the codebase, I may end up normalizing tabs and spacing somewhat; e.g. tabs between 'if', 'while', 'for' and '(', spaces between function / array name and '(' or '[', etc. That is to say, I don't mind everyone being free to format code how they see fit, just don't be surprised if in rewriting or modifying it, it gets "fixed" differently. I'm currently doing this right now at work, hence my vehemence. There's even things like this in class definitions: int const * const FooBar // Yes, that's a tab (Foo foo, Bar bar) which at first glance can end up looking like instance variable declarations instead of methods.
- T-R 16y ago
  I probably shouldn't have left it at that - if there's much regularity outside of tables, then you're definitely doing something wrong. Within code I see the alignment as a way of highlighting regular areas as potential spots for refactoring. Sometimes it doesn't make sense to turn something into another layer of abstraction yet, but it may later. I can certainly see how the extra spacing might grate on some people's nerve's, though. Edit: Something I hadn't thought of - you mention "rivers of space" - aligning code might make it harder to read for coders with dyslexia: http://uxmovement.com/content/6-surprising-bad-practices-that-hurt-dyslexic-users http://uxmovement.com/content/6-surprising-bad-practices-tha... Regarding your point about unsigned types - If I'm remembering correctly, "Writing Solid Code" had a section about exactly that - nasty bugs caused by things like looping over unsigned integers in reverse.
- Luyt 16y ago
  I'm one of those few programmers who like to code with a proportional font. I have been declared mad as such, with the reasoning "you can't line up things with a proportional font". Well, guess what, I don't need to. I pay attention to correctly indenting my code, and that works even with proportional fonts. I find monospaced fonts hard and unnatural to read. Almost all books, magazines and newspapers use proportional fonts! If your code needs lining up to be legible, you're doing something wrong.

> Align everything you can in code Yes. Makes code easier to read and makes it easier to refactor if you use an editor with column select/multi-line caret.

by T-R 16y ago

> Align everything you can in code Yes. Makes code easier to read and makes it easier to refactor if you use an editor with column select/multi-line caret.

barrkel 16y ago

I personally detest people who do this, outside of things like tables (i.e. structured constant initializers) and comments on type definitions. If there's a high degree of regularity in the source that you're trying to expose, there's probably a better way of doing it - extracting out common variables, using a table lookup, adopting acronym conventions for regular parts along any given axis which have the same length, so that the code naturally lines up without ugly random rivers of space down the middle. Unsigned types, on the other hand, are just evil. Way too many people use an unsigned type because they think it represents an invariant that this value will never be negative, that it has some kind of documentation or safety aspect, but that's just wrong. Unsigned types don't act according to the intuitions of most average programmers, and things as simple as for-loops are incredibly easy to get wrong with them (e.g. think about the most common idiom for iterating backwards in C derivatives). If I had my druthers, mixing signed and unsigned ought to expand the expression to the next larger signed type that can represent the range of both (and error out if there is none), and there ought to be separate subtraction / decrement operators specifically for unsigned types. 'u += -2' where u is unsigned would be a type error - assigning a signed value to an unsigned location.

Stormbringer 16y ago
Sometimes I arrange my variable declarations so that they make a picture of something in profile... ... don't hate me because I'm beautiful ... :D ---- On a more serious note, something I have noticed working on large projects with other programmers, is that if each programmer has their own distinctive style and conventions, then you can tell straight away by looking at it who wrote it, and more importantly who modified it. Thus if Billy (who is an idiot) modified something written by Sheila (who is like unto the goddess of inspired poetry in wisdom and understanding), and the whole is broken, you can pretty much bet that it is Billy's modification that has broken it, and you can spot his bits straight away, this makes debugging a lot easier. I think this is one of the more unfortunate side-effects of things like checkstyle and other forms of overly restrictive style enforcement. The more we sand-paper everybody back to the same (low) level of code appearance, the more information is lost for what I like to call "forensic debugging".
- barrkel 16y ago
  I strongly agree with this as well - however, when I need to overhaul a huge portion of the codebase, I may end up normalizing tabs and spacing somewhat; e.g. tabs between 'if', 'while', 'for' and '(', spaces between function / array name and '(' or '[', etc. That is to say, I don't mind everyone being free to format code how they see fit, just don't be surprised if in rewriting or modifying it, it gets "fixed" differently. I'm currently doing this right now at work, hence my vehemence. There's even things like this in class definitions: int const * const FooBar // Yes, that's a tab (Foo foo, Bar bar) which at first glance can end up looking like instance variable declarations instead of methods.
T-R 16y ago
I probably shouldn't have left it at that - if there's much regularity outside of tables, then you're definitely doing something wrong. Within code I see the alignment as a way of highlighting regular areas as potential spots for refactoring. Sometimes it doesn't make sense to turn something into another layer of abstraction yet, but it may later. I can certainly see how the extra spacing might grate on some people's nerve's, though. Edit: Something I hadn't thought of - you mention "rivers of space" - aligning code might make it harder to read for coders with dyslexia: http://uxmovement.com/content/6-surprising-bad-practices-that-hurt-dyslexic-users http://uxmovement.com/content/6-surprising-bad-practices-tha... Regarding your point about unsigned types - If I'm remembering correctly, "Writing Solid Code" had a section about exactly that - nasty bugs caused by things like looping over unsigned integers in reverse.
Luyt 16y ago
I'm one of those few programmers who like to code with a proportional font. I have been declared mad as such, with the reasoning "you can't line up things with a proportional font". Well, guess what, I don't need to. I pay attention to correctly indenting my code, and that works even with proportional fonts. I find monospaced fonts hard and unnatural to read. Almost all books, magazines and newspapers use proportional fonts! If your code needs lining up to be legible, you're doing something wrong.