7 ms·

Nowadays I couldn't care less about what style is used. As long as the code is consistent and there's an easy way to adhere (clang-format, black, prettier, etc.

by crehn 8y ago

Nowadays I couldn't care less about what style is used. As long as the code is consistent and there's an easy way to adhere (clang-format, black, prettier, etc.) I'm happy.

mruts 8y ago
I don't think even you believes that. You're telling me you would be "happy" if every source file was one line?
- xboxnolifes 8y ago
  Just replace "style" with "half reasonable style".
- gdfasfklshg4 8y ago
  Lint to personally preferred style on checkout. Lint to project style on checkin. Not a problem.
  - hyperpape 8y ago
    Do you actually do this? From what I hear (and this makes sense from what I know about formatting/parsing algorithms) it's a huge pain, and not implemented for many languages.
    - emodendroket 8y ago
      I have my IDE do all the formatting every time I close something and rarely personally intervene.
      - hyperpape 8y ago
        That's easyish: it's a one-way street. The OP imagined something where everyone checks out code in whatever state it's in, applies their own system, then transforms it back, with no artifacts. That's hard.
      - Ace17 8y ago
        Same here, with a twist: the test suite does: global reformat (uncrustify or astyle, depending on the team), build, run the actual tests. As people almost always run the test suite before checking code in, all the project stays properly formatted. My experience is: each time a team started doing this, all coding-style related discussions vanished, and it became a non-issue. It turns out it's a lot easier to accept a coding style you're not the one doing the actual formatting (this is why, BTW, I think stylechecking hooks alone are a bad idea).
frou_dh 8y ago
Put another way... if the proponent of a particular (serious) syntax style guide can't be bothered to automate it, then they are pissing in the wind. I laugh when I see those 50-page English-language documents describing how some institution wants code to be formatted. Ain't nobody got time for that.
- emodendroket 8y ago
  There are some limits to what you can automate but stuff like spacing should definitely be enforced by a tool.
  - jeremy_wiebe 8y ago
    I feel like Prettier does a really good job with JavaScript. What situations have you found where automated formatting doesn’t suffice or has these limits?
    - paulddraper 8y ago
      Ordering code. Some tools order/deduplicate imports. Prettier does not. [1] And no tool that I've seen orders fields/constructor/method, etc. [1] https://github.com/prettier/prettier/issues/949 https://github.com/prettier/prettier/issues/949
      - jeremy_wiebe 8y ago
        Interesting, yeah, that’s definitely missing. ESLint has rules for ordering, feels like it’d be a relatively simple addition to prettier.
        eropple 8y ago
        In JavaScript, imports sometimes (too often, really) have side effects. I don't know if it makes sense for prettier to do that, at least by default.
brixon 8y ago
Consistency is key. Follow the style that the code already uses. For new apps, I make sure the team has the same style template and use the editor to format the page. At the end of the day, it is important that the code looks like it was written by one consistent person and not 20 random different people.
- emodendroket 8y ago
  Unless the code you're working on combines different styles not only in the same project bet even in the same file.
- deckard1 8y ago
  pet peeve #1 right here. I really don't like the mandatory use of eslint (used as style enforcement), prettier, etc. When used as a bat to hit developers over the head, all this tells me is that the organization has too many anti-social developers that can't check their ego at the door. Often someone will recommend a tool or technology in place of simple social common sense. If a developer can't follow the existing code style, they should be shunned. It's their problem. It's not a problem to solve with a fancy tool. You solve this particular problem by telling that person that they are an asshole. Using technology to solve social problems just exacerbates the problem. All of that leads to a situation where we can't have nice things. You go into a codebase and see hundreds of exceptions to turn off eslint or whatever. Instead of just working around one-off style exceptions with common sense (who really gives a damn if a line needs broken/indented a certain way for a specific function) you have to plead with the style cops to let you off each and every time. Developers really hate each other. Small organizations or teams tend to be a bit better in my experience. There is more camaraderie. But I often feel like I'm in a group of mercenaries, each ready to stab you in the back.
  - britch 8y ago
    Linters save so much formatting time, I don't really see what it has to do with ego. I certainly could go through and make sure all the spacing is exactly right, the functions/properties are in the right place, and rest of the rules of the styleguide are followed. But it's much easier to do when you get a warning, squiggly, or can use an autoformatter to match the rules. I would never intentionally violate a rule, but I might forget a rule or miss a violation. With linters this is not an issue, the machine will let you know. Everyone can focus on the correctness and quality of code and let the machine worry about making sure everything is formatted correctly. Clearly the project you describe, where linting is disabled every other line is bad. But I wouldn't blame the linter for that. I don't know what can be done if a team has such a commitment to their own style that they put in the extra work to disable the linter. A linter is not a tool for punishing people who violate a style guide, it's an assistant for people who are trying to follow a style guide.
LiterallyDoge 8y ago
Sign of an experienced architect. Read: "I'm old and too tired to argue, just don't break it ok."
- gagege 8y ago
  I'm 32 and I feel like I'm already at that stage sometimes. What will I be like when I'm 50?
  - LiterallyDoge 8y ago
    Better.
  - GnarfGnarf 8y ago
    I'm 70, push out production code every day (Horstmann style https://en.wikipedia.org/wiki/Indentation_style#Horstmann_style https://en.wikipedia.org/wiki/Indentation_style#Horstmann_st...), and I'm having the time of my life.
    - marvy 8y ago
      Horstmann style looks like my ideal, but there's very little tool support for it, from what I've seen. For instance, if I want to swap the first two lines of an "if" statement, I can't use "line-based" copy/paste. Do you do things manually, or does your editor support it fairly well? EDIT: looks like the tool support is so bad, Horstmann himself pretty much gave up: http://horstmann.com/unblog/2010-06-28/braces.html http://horstmann.com/unblog/2010-06-28/braces.html

by crehn 8y ago

Nowadays I couldn't care less about what style is used. As long as the code is consistent and there's an easy way to adhere (clang-format, black, prettier, etc.) I'm happy.

mruts 8y ago

I don't think even you believes that. You're telling me you would be "happy" if every source file was one line?

xboxnolifes 8y ago
Just replace "style" with "half reasonable style".
gdfasfklshg4 8y ago
Lint to personally preferred style on checkout. Lint to project style on checkin. Not a problem.
- hyperpape 8y ago
  Do you actually do this? From what I hear (and this makes sense from what I know about formatting/parsing algorithms) it's a huge pain, and not implemented for many languages.
  - emodendroket 8y ago
    I have my IDE do all the formatting every time I close something and rarely personally intervene.
    - hyperpape 8y ago
      That's easyish: it's a one-way street. The OP imagined something where everyone checks out code in whatever state it's in, applies their own system, then transforms it back, with no artifacts. That's hard.
    - Ace17 8y ago
      Same here, with a twist: the test suite does: global reformat (uncrustify or astyle, depending on the team), build, run the actual tests. As people almost always run the test suite before checking code in, all the project stays properly formatted. My experience is: each time a team started doing this, all coding-style related discussions vanished, and it became a non-issue. It turns out it's a lot easier to accept a coding style you're not the one doing the actual formatting (this is why, BTW, I think stylechecking hooks alone are a bad idea).

frou_dh 8y ago

Put another way... if the proponent of a particular (serious) syntax style guide can't be bothered to automate it, then they are pissing in the wind. I laugh when I see those 50-page English-language documents describing how some institution wants code to be formatted. Ain't nobody got time for that.

emodendroket 8y ago
There are some limits to what you can automate but stuff like spacing should definitely be enforced by a tool.
- jeremy_wiebe 8y ago
  I feel like Prettier does a really good job with JavaScript. What situations have you found where automated formatting doesn’t suffice or has these limits?
  - paulddraper 8y ago
    Ordering code. Some tools order/deduplicate imports. Prettier does not. [1] And no tool that I've seen orders fields/constructor/method, etc. [1] https://github.com/prettier/prettier/issues/949 https://github.com/prettier/prettier/issues/949
    - jeremy_wiebe 8y ago
      Interesting, yeah, that’s definitely missing. ESLint has rules for ordering, feels like it’d be a relatively simple addition to prettier.
      - eropple 8y ago
        In JavaScript, imports sometimes (too often, really) have side effects. I don't know if it makes sense for prettier to do that, at least by default.

brixon 8y ago

Consistency is key. Follow the style that the code already uses. For new apps, I make sure the team has the same style template and use the editor to format the page. At the end of the day, it is important that the code looks like it was written by one consistent person and not 20 random different people.

emodendroket 8y ago
Unless the code you're working on combines different styles not only in the same project bet even in the same file.
deckard1 8y ago
pet peeve #1 right here. I really don't like the mandatory use of eslint (used as style enforcement), prettier, etc. When used as a bat to hit developers over the head, all this tells me is that the organization has too many anti-social developers that can't check their ego at the door. Often someone will recommend a tool or technology in place of simple social common sense. If a developer can't follow the existing code style, they should be shunned. It's their problem. It's not a problem to solve with a fancy tool. You solve this particular problem by telling that person that they are an asshole. Using technology to solve social problems just exacerbates the problem. All of that leads to a situation where we can't have nice things. You go into a codebase and see hundreds of exceptions to turn off eslint or whatever. Instead of just working around one-off style exceptions with common sense (who really gives a damn if a line needs broken/indented a certain way for a specific function) you have to plead with the style cops to let you off each and every time. Developers really hate each other. Small organizations or teams tend to be a bit better in my experience. There is more camaraderie. But I often feel like I'm in a group of mercenaries, each ready to stab you in the back.
- britch 8y ago
  Linters save so much formatting time, I don't really see what it has to do with ego. I certainly could go through and make sure all the spacing is exactly right, the functions/properties are in the right place, and rest of the rules of the styleguide are followed. But it's much easier to do when you get a warning, squiggly, or can use an autoformatter to match the rules. I would never intentionally violate a rule, but I might forget a rule or miss a violation. With linters this is not an issue, the machine will let you know. Everyone can focus on the correctness and quality of code and let the machine worry about making sure everything is formatted correctly. Clearly the project you describe, where linting is disabled every other line is bad. But I wouldn't blame the linter for that. I don't know what can be done if a team has such a commitment to their own style that they put in the extra work to disable the linter. A linter is not a tool for punishing people who violate a style guide, it's an assistant for people who are trying to follow a style guide.

LiterallyDoge 8y ago

Sign of an experienced architect. Read: "I'm old and too tired to argue, just don't break it ok."

gagege 8y ago
I'm 32 and I feel like I'm already at that stage sometimes. What will I be like when I'm 50?
- LiterallyDoge 8y ago
  Better.
- GnarfGnarf 8y ago
  I'm 70, push out production code every day (Horstmann style https://en.wikipedia.org/wiki/Indentation_style#Horstmann_style https://en.wikipedia.org/wiki/Indentation_style#Horstmann_st...), and I'm having the time of my life.
  - marvy 8y ago
    Horstmann style looks like my ideal, but there's very little tool support for it, from what I've seen. For instance, if I want to swap the first two lines of an "if" statement, I can't use "line-based" copy/paste. Do you do things manually, or does your editor support it fairly well? EDIT: looks like the tool support is so bad, Horstmann himself pretty much gave up: http://horstmann.com/unblog/2010-06-28/braces.html http://horstmann.com/unblog/2010-06-28/braces.html