3 ms·

I must be the only person who honestly doesn't care a whole lot. At the end of the day, good programming comes from good design. If you think about what's going

I must be the only person who honestly doesn't care a whole lot. At the end of the day, good programming comes from good design. If you think about what's going on and the interfaces it ought to have, then the style of the implementation is not super important. In fact, insofar as different teams / groups may be quicker at one style than another, it would be better to just go along with it.

Retr0id 3y ago
If style is not important, it seems like all the more reason to standardize it.
- velcrovan 3y ago
  I am pro-standardize, but this isn't a great argument. Enforcing a standard style takes resources from both the language and the people using it. You don't spend resources on something that isn't important.
  - Retr0id 3y ago
    Coming up with and agreeing on a standard takes work, but in most cases unofficial standards already exist - one merely needs to be blessed. (And if some project wants to not use it, that's also free)
  - deleted 3y ago
    [deleted]
- anon291 3y ago
  Well... no. Engineers are more efficient in their own styles. Realistically, I've wasted hours setting up my editor at each new job / each project to get on board with the style. This really doesn't matter. Maybe it's just me, but I feel that a good engineer ought to be able to read code regardless of the indentation or particular language dialect (within reason). When I've led teams, I've never enforced things like indentation or bracketing styles. Things I do enforce are (1) explain complicated code with comments, (2) make it readable (for whatever definition of readable), and (3) reasonable naming conventions (i.e., don't name every variable i, j, k). These guidelines are useless for automated tooling. Perhaps in the age of LLMs this will change (who knows). I've found the strict requirements and automated tooling absolutely terrible. I often align things to keep parallel structure to show how different lines are the same or to create 'tables', etc. Formatting tools destroy this. For me, using my emacs rectangular editing, the alignment greatly increases productivity. This is one example. I'm much faster at editing personal projects / projects I've led than ones with strict style guidelines. For me, I always tell my guys: edit in the style in which you are fastest and most efficient. I believe this greatly increases productivity rather than having a team 'nosy neighbor' that cares whether you use two or four spaces for indentation. My two cents.
  - zeroxfe 3y ago
    Your approach seems like the worst of both worlds: a single codebase with mixed styles. I work at a large tech company, and while I don't really participate in style wars, I do care that there is a single enforced standard across any particular codebase.
  - axelerator 3y ago
    > Well... no. Engineers are more efficient in their own styles. Realistically, I've wasted hours setting up my editor at each new job / each project to get on board with the style I disagree for two reasons: 1. Optimizing for what each dev is used to is optimizing for a local maximum. If they’re THAT good it won’t take them long to adjust to new defaults. Good engineers should be able to pick up a new lang quickly so some changes in the context of a language should not bog them down significantly in the long term. 2. The overly long time it took to set up tooling in a particular company or language do not outweigh the bigger advantage of being able to quickly get a grasp about what a piece of completely unfamiliar code does.
  - pnathan 3y ago
    That is my take, after having written in many languages over many years. I also think this is more of a Zeitgeist thing, to be honest.
- erikerikson 3y ago
  Yes, as you say because the style is not important. Consider the wasted time on arguments between tabs and spaces and how many spaces; the noise in PRs from style conversions that hide the actual additions and alterations; the increased efficiency that comes from learning and using the shapes of a codebase to more quickly seek. It doesn't matter what the style convention is so long as you have one, you have automated tooling that creates and validates it, and that enforcement is done by machines as part of the delivery process. Not because style is valuable but because time is a valuable resource and spending it on preference differences and dealing with variances is wasteful.
dangets 3y ago
I'm thinking that it is largely psychological/OCD tendencies that affect programmers at different magnitudes. It can sometimes be difficult to not be distracted by the minor style inconsistencies before being able to focus on the larger system design.
iopq 3y ago
So you don't somehow end up with mismatched curly braces? I might paste something, but mess up and forget to select one of the curly braces or select too many. I am seriously considering closing all of them on the same line in this style if blah { thing; }
mattgreenrocks 3y ago
Code style is easy to discuss, thus it sucks up the oxygen in the room that should be used for design discussions.
- ludston 3y ago
  It's another example of bikeshedding.
michaelt 3y ago
In my experience a large project needs, at the very least: * Indenting consistent with the curly braces, and well enough defined that when you remove an outer loop and want to unindent the code from that block, you don't have to do it by hand. * A one-line code change doesn't bring with it a 500-line style change because the file passed between people with different style tastes. Unfortunately, it's often difficult to achieve these modest desires without someone also wanting to limit line lengths, ban the ternary operator, ban nulls, and so on...
- anon291 3y ago
  > * A one-line code change doesn't bring with it a 500-line style change because the file passed between people with different style tastes. In general, one should refrain from drive-by refactoring.
  - deleted 3y ago
    [deleted]
- threatofrain 3y ago
  Just use a style formatter and the debate is done. Everyone is unhappy now. Or very happy due to not arguing.
  - mgaunard 3y ago
    In my career the only people I saw arguing for auto style formatters are people that were simply unable to systematically follow simple rules, and that you're better off without.
    - threatofrain 3y ago
      I'm afraid anyone who uses Tailwind is almost certainly using a style formatter to auto-arrange the CSS.
    - vundercind 3y ago
      Why in god’s name would programmers of all people resist letting computers handle “systematically [applying] simple rules” for us automatically?
deleted 3y ago
[deleted]

Retr0id 3y ago

If style is not important, it seems like all the more reason to standardize it.

velcrovan 3y ago
I am pro-standardize, but this isn't a great argument. Enforcing a standard style takes resources from both the language and the people using it. You don't spend resources on something that isn't important.
- Retr0id 3y ago
  Coming up with and agreeing on a standard takes work, but in most cases unofficial standards already exist - one merely needs to be blessed. (And if some project wants to not use it, that's also free)
- deleted 3y ago
  [deleted]
anon291 3y ago
Well... no. Engineers are more efficient in their own styles. Realistically, I've wasted hours setting up my editor at each new job / each project to get on board with the style. This really doesn't matter. Maybe it's just me, but I feel that a good engineer ought to be able to read code regardless of the indentation or particular language dialect (within reason). When I've led teams, I've never enforced things like indentation or bracketing styles. Things I do enforce are (1) explain complicated code with comments, (2) make it readable (for whatever definition of readable), and (3) reasonable naming conventions (i.e., don't name every variable i, j, k). These guidelines are useless for automated tooling. Perhaps in the age of LLMs this will change (who knows). I've found the strict requirements and automated tooling absolutely terrible. I often align things to keep parallel structure to show how different lines are the same or to create 'tables', etc. Formatting tools destroy this. For me, using my emacs rectangular editing, the alignment greatly increases productivity. This is one example. I'm much faster at editing personal projects / projects I've led than ones with strict style guidelines. For me, I always tell my guys: edit in the style in which you are fastest and most efficient. I believe this greatly increases productivity rather than having a team 'nosy neighbor' that cares whether you use two or four spaces for indentation. My two cents.
- zeroxfe 3y ago
  Your approach seems like the worst of both worlds: a single codebase with mixed styles. I work at a large tech company, and while I don't really participate in style wars, I do care that there is a single enforced standard across any particular codebase.
- axelerator 3y ago
  > Well... no. Engineers are more efficient in their own styles. Realistically, I've wasted hours setting up my editor at each new job / each project to get on board with the style I disagree for two reasons: 1. Optimizing for what each dev is used to is optimizing for a local maximum. If they’re THAT good it won’t take them long to adjust to new defaults. Good engineers should be able to pick up a new lang quickly so some changes in the context of a language should not bog them down significantly in the long term. 2. The overly long time it took to set up tooling in a particular company or language do not outweigh the bigger advantage of being able to quickly get a grasp about what a piece of completely unfamiliar code does.
- pnathan 3y ago
  That is my take, after having written in many languages over many years. I also think this is more of a Zeitgeist thing, to be honest.
erikerikson 3y ago
Yes, as you say because the style is not important. Consider the wasted time on arguments between tabs and spaces and how many spaces; the noise in PRs from style conversions that hide the actual additions and alterations; the increased efficiency that comes from learning and using the shapes of a codebase to more quickly seek. It doesn't matter what the style convention is so long as you have one, you have automated tooling that creates and validates it, and that enforcement is done by machines as part of the delivery process. Not because style is valuable but because time is a valuable resource and spending it on preference differences and dealing with variances is wasteful.

dangets 3y ago

I'm thinking that it is largely psychological/OCD tendencies that affect programmers at different magnitudes. It can sometimes be difficult to not be distracted by the minor style inconsistencies before being able to focus on the larger system design.

iopq 3y ago

So you don't somehow end up with mismatched curly braces? I might paste something, but mess up and forget to select one of the curly braces or select too many. I am seriously considering closing all of them on the same line in this style if blah { thing; }

mattgreenrocks 3y ago

Code style is easy to discuss, thus it sucks up the oxygen in the room that should be used for design discussions.

ludston 3y ago
It's another example of bikeshedding.

michaelt 3y ago

In my experience a large project needs, at the very least: * Indenting consistent with the curly braces, and well enough defined that when you remove an outer loop and want to unindent the code from that block, you don't have to do it by hand. * A one-line code change doesn't bring with it a 500-line style change because the file passed between people with different style tastes. Unfortunately, it's often difficult to achieve these modest desires without someone also wanting to limit line lengths, ban the ternary operator, ban nulls, and so on...

anon291 3y ago
> * A one-line code change doesn't bring with it a 500-line style change because the file passed between people with different style tastes. In general, one should refrain from drive-by refactoring.
- deleted 3y ago
  [deleted]
threatofrain 3y ago
Just use a style formatter and the debate is done. Everyone is unhappy now. Or very happy due to not arguing.
- mgaunard 3y ago
  In my career the only people I saw arguing for auto style formatters are people that were simply unable to systematically follow simple rules, and that you're better off without.
  - threatofrain 3y ago
    I'm afraid anyone who uses Tailwind is almost certainly using a style formatter to auto-arrange the CSS.
  - vundercind 3y ago
    Why in god’s name would programmers of all people resist letting computers handle “systematically [applying] simple rules” for us automatically?

deleted 3y ago

[deleted]