5 ms·

Mixed is the worst. It doesn't make sense logically. Isn't indentation just another kind of 'alignment'? After all, we use indentation to align text on the pag

Mixed is the worst. It doesn't make sense logically. Isn't indentation just another kind of 'alignment'? After all, we use indentation to align text on the page... The differences between between all the supposedly distinct kinds of alignment are too subtle and difficult to describe in words to be used as a rule. It's better to stick to simple rules that are easy to follow and enforce - Leave no room for ambiguous interpretations. Also, I hate it when developers try to break up code in weird ways to align all the equal signs together for example. I would prefer that they never do this. Maybe if our eyeballs were stuck inside our heads in such a way we had to move our necks to read each letter, then it would be a good idea... Then it would be worth the complexity it adds. In the real world, however, moving one's eyeballs a few millimetres sideways isn't very difficult. There is no need to litter your pristine code with extra spaces just to save people from having to shift their eyeballs a bit when reading your code. You save the reader like 10 eyeball shifts out of 1000...

benrbray 5y ago
> I hate it when developers try to break up code in weird ways to align all the equal signs together for example. I do this in cases where I have many similar lines, for instance calling the same function many times with different arguments, and I want to make the differences between them more obvious. I find it to be much more maintainable and easier to read / identify bugs.
- cryptica 5y ago
  I find that the skill of reading code correctly without relying on visual aids can be trained and is a valuable skill. Visual aids won't help you to train this skill. I'm confident that my ability to identify potential bugs quickly is correlated to my ability to visually spot tiny differences in the code. In both cases, you need to develop an extreme attention to detail.
  - benrbray 5y ago
    It's one of those tradeoffs we make to save time. I get practice tracing program logic by reading poorly organized code written by others, but for my own purposes, I have a standard, consistent way of organizing/formatting things that saves a lot of mental overhead. People make the same argument about static vs dynamic types -- "if you were a better programmer you wouldn't NEED to rely on type information!". Sure, I can juggle type information in my head just as well as anyone, but static types let me focus that mental effort somewhere else, and make context switching much easier. What is language syntax but a visual aid that we all use to avoid writing assembly?
    - cryptica 5y ago
      >> Sure, I can juggle type information in my head just as well as anyone, but static types let me focus that mental effort somewhere else, and make context switching much easier. That is an extremely interesting argument. Personally, I find that overhead to be useful; the difficulty of keeping track of all the different types encourages me to design simpler interfaces between components. When I'm struggling with remembering what type some variable is, I know I've made the method interface too complicated (e.g. maybe the component should just keep the instance state internally and only accept an ID instead of a whole instance as argument). I guess that's why I prefer dynamic typing; it forces me to keep my interfaces simple and to think more carefully about state and logic co-location (to get high cohesion, loose coupling). I like the Alan Kay quote about OOP "The Big Idea is Messaging". To understand this quote properly, we need to understand what "Messaging" means; it's about communication. Effective communication is about conveying intent; components should tell each other what needs to be done, not how to do it. Having complex interfaces which accept complex instances as arguments is akin to micro-managing the component. Typed languages are only particularly useful if you have complex interfaces. If you have simple method interfaces, you don't need a typed language because remembering what the parameters are for each method is trivial.
- Symbiote 5y ago
  I would do the same, but it's unfortunately becoming more common for code formatting to be enforced with plugins, GitHub actions etc. start = getData( 0, 0) middle = getData( 50, -50) end = getData(100, -100) I would also exceed the line limit, if the arguments to only 1 of these lines are a bit longer. But apparently we now have to live with this: start = getData(0, 0, 0, 0) middle = getData(50000, -50000, 50000, -50000) end = getData(100000, -100000, 1000000, -100000) (I have, completely accidentally, an extra zero in this. It would be easier to spot if it were aligned.)
  - deleted 5y ago
    [deleted]
  - Firadeoclus 5y ago
    This is a good example. I think the ideal way to support this would be an editor/IDE using tables for alignment. The compiler doesn't need to know about tables, whatever information the editor needs could be encoded entirely in a comment line preceding the table contents (which the editor would hide/replace with the table header unless the user chooses to reveal it). Anyone using another editor would simply see a somewhat cryptic comment line followed by aligned code. And table-supporting editors could use a content hash to detect changes in the table contents and inform the user.
    - Symbiote 5y ago
      Elastic Tabstops is similar to what you propose, but using tab characters to form the tables: https://nickgravgaard.com/elastic-tabstops/#solution https://nickgravgaard.com/elastic-tabstops/#solution But it's 15 years since that was proposed.
      - Firadeoclus 5y ago
        Similar, and I like the idea of Elastic Tabstops. A significant difference is that Elastic Tabstops won't look right in an editor that doesn't support them. What I'm suggesting would use spaces in the file and put metadata in a comment (though it could be stored elsewhere, too).

benrbray 5y ago

> I hate it when developers try to break up code in weird ways to align all the equal signs together for example. I do this in cases where I have many similar lines, for instance calling the same function many times with different arguments, and I want to make the differences between them more obvious. I find it to be much more maintainable and easier to read / identify bugs.

cryptica 5y ago
I find that the skill of reading code correctly without relying on visual aids can be trained and is a valuable skill. Visual aids won't help you to train this skill. I'm confident that my ability to identify potential bugs quickly is correlated to my ability to visually spot tiny differences in the code. In both cases, you need to develop an extreme attention to detail.
- benrbray 5y ago
  It's one of those tradeoffs we make to save time. I get practice tracing program logic by reading poorly organized code written by others, but for my own purposes, I have a standard, consistent way of organizing/formatting things that saves a lot of mental overhead. People make the same argument about static vs dynamic types -- "if you were a better programmer you wouldn't NEED to rely on type information!". Sure, I can juggle type information in my head just as well as anyone, but static types let me focus that mental effort somewhere else, and make context switching much easier. What is language syntax but a visual aid that we all use to avoid writing assembly?
  - cryptica 5y ago
    >> Sure, I can juggle type information in my head just as well as anyone, but static types let me focus that mental effort somewhere else, and make context switching much easier. That is an extremely interesting argument. Personally, I find that overhead to be useful; the difficulty of keeping track of all the different types encourages me to design simpler interfaces between components. When I'm struggling with remembering what type some variable is, I know I've made the method interface too complicated (e.g. maybe the component should just keep the instance state internally and only accept an ID instead of a whole instance as argument). I guess that's why I prefer dynamic typing; it forces me to keep my interfaces simple and to think more carefully about state and logic co-location (to get high cohesion, loose coupling). I like the Alan Kay quote about OOP "The Big Idea is Messaging". To understand this quote properly, we need to understand what "Messaging" means; it's about communication. Effective communication is about conveying intent; components should tell each other what needs to be done, not how to do it. Having complex interfaces which accept complex instances as arguments is akin to micro-managing the component. Typed languages are only particularly useful if you have complex interfaces. If you have simple method interfaces, you don't need a typed language because remembering what the parameters are for each method is trivial.
Symbiote 5y ago
I would do the same, but it's unfortunately becoming more common for code formatting to be enforced with plugins, GitHub actions etc. start = getData( 0, 0) middle = getData( 50, -50) end = getData(100, -100) I would also exceed the line limit, if the arguments to only 1 of these lines are a bit longer. But apparently we now have to live with this: start = getData(0, 0, 0, 0) middle = getData(50000, -50000, 50000, -50000) end = getData(100000, -100000, 1000000, -100000) (I have, completely accidentally, an extra zero in this. It would be easier to spot if it were aligned.)
- deleted 5y ago
  [deleted]
- Firadeoclus 5y ago
  This is a good example. I think the ideal way to support this would be an editor/IDE using tables for alignment. The compiler doesn't need to know about tables, whatever information the editor needs could be encoded entirely in a comment line preceding the table contents (which the editor would hide/replace with the table header unless the user chooses to reveal it). Anyone using another editor would simply see a somewhat cryptic comment line followed by aligned code. And table-supporting editors could use a content hash to detect changes in the table contents and inform the user.
  - Symbiote 5y ago
    Elastic Tabstops is similar to what you propose, but using tab characters to form the tables: https://nickgravgaard.com/elastic-tabstops/#solution https://nickgravgaard.com/elastic-tabstops/#solution But it's 15 years since that was proposed.
    - Firadeoclus 5y ago
      Similar, and I like the idea of Elastic Tabstops. A significant difference is that Elastic Tabstops won't look right in an editor that doesn't support them. What I'm suggesting would use spaces in the file and put metadata in a comment (though it could be stored elsewhere, too).