5 ms·

You're not the only one. As a freelance/contractor, my environments change, often daily/weekly. I routinely switch between Java, PHP, Vue, React and some othe

You're not the only one. As a freelance/contractor, my environments change, often daily/weekly. I routinely switch between Java, PHP, Vue, React and some other tools. Doesn't matter WHAT I do, I end up having some stupid red squiggles telling me I can't use "double-quotes" or that I can't use 'single-quotes', depending on context. Multiple languages and 'community standards' conflict with each other, and I'm always constantly having to double check things and 'clean up' stuff. And... conforming to all of these various 'standards' has not increased the speed of development, nor the robustness, nor the client satisfaction. It does mean that some people who place a high value on standards and listing and visual style are placated. Increase of automated testing and documentation have more value - long term and short term. And I understand it's not an 'either/or', but visual style and 'linting' standards are low-hanging fruit that are immediately visible, so tend to get more attention (and ongoing). And then in group discussions, I end up being the person who is apparently "AGAINST CODE STANDARDS". I'm not terribly against them, but in the projects I end up being involved in, it's lower value. I've got project one which insisted - the point of blocking PRs - that "Yoda style" for null checks was mandatory. Guess what? Another project I'm on, Yoda-style is prohibited, because "it's confusing". Every keystroke I'm having to wonder/worry about what context am I in, and always battling stupid red squiggles. If you spend 40+ hrs/week using one and one one tech platform where you can have one standard to follow and adhere to - great. I switch platforms, teams and projects regularly, and it's soured me on the huge importance some people place on linting.

musingsole 6y ago
> It does mean that some people who place a high value on standards and listing and visual style are placated. This times a million. It doesn't help that the advocates of linting are so dogmatic about the whole idea (as demonstrated so colorfully in this thread and this sub-thread in particular). I mean, I understand why. Linting is an all or nothing type of thing. But I'm still going to remember the lint-advocate as a developer too concerned with the wrong things.
- lowercased 6y ago
  I joined a project - small startup - code in production for... 4 months at this point. 0 tests of any sort. First week, I do a small feature, add a test, and it was blocked, because I used a single letter variable name in a data setup method in a test file. "Single letter variables aren't professional". Developing and pushing code with no tests for 6+ months apparently is just fine though. I was tempted to use a four-letter variable name... They then got automated-linting fever.
- userbinator 6y ago
  I think it's mainly the difference between result- and process-oriented personalities, with the latter being advocates of linting and other "formalities", and the former opposing it. As someone in the former group, I completely agree that these sorts of things bring little value; the fact that the code works is the most important, regardless of how it looks. If your coworkers are writing code that's not working or misleading, talk to them about it. I've got project one which insisted - the point of blocking PRs - that "Yoda style" for null checks was mandatory. Guess what? Another project I'm on, Yoda-style is prohibited, because "it's confusing". Every keystroke I'm having to wonder/worry about what context am I in, and always battling stupid red squiggles. That sort of insignificant minutiae really irritates me. It shouldn't matter at all, yet some people love to make mountains out of molehills. (I personally use the "if(ptr)" style because it's the simplest, but I wouldn't care if my coworkers used "if(NULL != ptr)", "if(ptr != NULL)", "if(ptr != 0)", or "if(0 != ptr)"; they're all equivalent, and anyone who doesn't know that, doesn't know the language. "if((NULL != ptr ) == true)" will cause me to raise a comment, however, although not a blocking one.)
  - lowercased 6y ago
    The justifications I've had over the years: "It means we don't have to argue about style" Well... for the most part, I wasn't arguing about your style in the first place. You're trying to get stuff done your way under the guise of "let's all stop fighting and just get along". I didn't start the fight. "It makes things easier to read" If it's harder for me (and some others) to write it that way, it's because it's not natural/default, and, actually, it might actually be harder for me (and some others) to read as well. I routinely work with folks who like to 'omit' 'unnecessary' lines - omitting a curly brace block in a one-line if is a regular example. if (foo) { bar } ends up as if (foo) bar or if (foo) bar Honestly I can't remember which. Had 'feedback' from people removing my braces saying "these are unnecessary". But now there's two styles I have to be able to read/write, and... there's almost never a time when one line without braces is sufficient forever - whenever I need logging or another piece of code in the block - bam - now I have to add braces, and that whole area of the code looks more 'different' than it used to.

musingsole 6y ago

> It does mean that some people who place a high value on standards and listing and visual style are placated. This times a million. It doesn't help that the advocates of linting are so dogmatic about the whole idea (as demonstrated so colorfully in this thread and this sub-thread in particular). I mean, I understand why. Linting is an all or nothing type of thing. But I'm still going to remember the lint-advocate as a developer too concerned with the wrong things.

lowercased 6y ago
I joined a project - small startup - code in production for... 4 months at this point. 0 tests of any sort. First week, I do a small feature, add a test, and it was blocked, because I used a single letter variable name in a data setup method in a test file. "Single letter variables aren't professional". Developing and pushing code with no tests for 6+ months apparently is just fine though. I was tempted to use a four-letter variable name... They then got automated-linting fever.
userbinator 6y ago
I think it's mainly the difference between result- and process-oriented personalities, with the latter being advocates of linting and other "formalities", and the former opposing it. As someone in the former group, I completely agree that these sorts of things bring little value; the fact that the code works is the most important, regardless of how it looks. If your coworkers are writing code that's not working or misleading, talk to them about it. I've got project one which insisted - the point of blocking PRs - that "Yoda style" for null checks was mandatory. Guess what? Another project I'm on, Yoda-style is prohibited, because "it's confusing". Every keystroke I'm having to wonder/worry about what context am I in, and always battling stupid red squiggles. That sort of insignificant minutiae really irritates me. It shouldn't matter at all, yet some people love to make mountains out of molehills. (I personally use the "if(ptr)" style because it's the simplest, but I wouldn't care if my coworkers used "if(NULL != ptr)", "if(ptr != NULL)", "if(ptr != 0)", or "if(0 != ptr)"; they're all equivalent, and anyone who doesn't know that, doesn't know the language. "if((NULL != ptr ) == true)" will cause me to raise a comment, however, although not a blocking one.)
- lowercased 6y ago
  The justifications I've had over the years: "It means we don't have to argue about style" Well... for the most part, I wasn't arguing about your style in the first place. You're trying to get stuff done your way under the guise of "let's all stop fighting and just get along". I didn't start the fight. "It makes things easier to read" If it's harder for me (and some others) to write it that way, it's because it's not natural/default, and, actually, it might actually be harder for me (and some others) to read as well. I routinely work with folks who like to 'omit' 'unnecessary' lines - omitting a curly brace block in a one-line if is a regular example. if (foo) { bar } ends up as if (foo) bar or if (foo) bar Honestly I can't remember which. Had 'feedback' from people removing my braces saying "these are unnecessary". But now there's two styles I have to be able to read/write, and... there's almost never a time when one line without braces is sufficient forever - whenever I need logging or another piece of code in the block - bam - now I have to add braces, and that whole area of the code looks more 'different' than it used to.