16 ms·

I've never understood why people care so much about the linter settings. It's so obviously bikeshedding, just make a choice, run the linter automatically and be

• jupp0r 1y ago
  I generally agree, but max line length being so high you have to horizontally scroll while reading code is very detrimental to productivity.
  • appellations 1y ago
    I forget there are people who don’t configure softwrap in their text editor. Some languages (java) really need the extra horizontal space if you can afford it and aren’t too hard to read when softwrapped.
  • forrestthewoods 1y ago
    Define high? I think 120 is pretty reasonable. Maybe even as high as 140. Log statements however I think have an effectively unbounded length. Nothing I hate more than a stupid linter turning a sprinkling of logs into 7 line monsters. cargo fmt is especially bad about this. It’s so bad.
    • skinner927 1y ago
      I still prefer 80. I won’t (publicly) scoff at 100 though. IMO 120 is reasonable for HTML and Java, but that’s about it. Sent from my 49” G9 Ultrawide.
      • forrestthewoods 1y ago
        Ugh. 80 is the worst. For C++ it’s entirely unreasonable. I definitely can not reconcile “linters make code easier to read” and “80 width is good”. Those are mutually exclusive imho. What I actually want from a linter is “120, unless the trailing bits aren’t interesting in which case 140+ is fine”. The ideal rule isn’t hard and fast! It’s not pure science. There’s an art to it.
      • Joker_vD 1y ago
        Give a try to 132 mode, maybe? It was the standard paper width for printouts since, well, forever.
        • psychoslave 1y ago
          Printing industry have not been anything close to forever, even writing is relatively novel compared to human spoken languages. All that said, I'm interested with this 132 number, where does it come from?
          • bloak 1y ago
            The IBM 1403 line printer, apparently.
          • dcminter 1y ago
            Printers aside the VT220 terminal from DEC had a 132 column mode. Probably it was aping a standard printer column count. Most of the time we used the 80 column mode as it was far more readable on what was quite a small screen.
            • guenthert 1y ago
              Not only a small screen by modern standards, but the hardware lacked the needed resolution. The marketing brochure claims a 10x10 dot matrix. That will be for the 80 column mode. That works out to respectable 800 pixel horizontally, barely sufficient 6x10 pixel in 132 column mode. There was even a double-high, double-width mode for easier reading ;-) Interesting here perhaps is that even back then it was recognized, that for different situations, different display modes were of advantage.
              • dcminter 1y ago
                > There was even a double-high, double-width mode for easier reading I'd forgotten that; now that waa a fugly font. I don't think anyone ever used it (aside from the "Setup" banner on the settings screen) I think the low pixel count was rather mitigated by the persistence of phospher though - there's reproductions of the fonts that had to take this into account; see the stuff about font stretching here: https://vt100.net/dec/vt220/glyphs https://vt100.net/dec/vt220/glyphs
      • typpilol 1y ago
        That's literally my setup everywhere. 120 for html/java/JavaScript and 80 elsewhere. Really suites each language imo Although I could probably get away with 80, habit to use tailwind classes can get messy compared to 120
        • Cthulhu_ 1y ago
          Caveat, my personal experience is mainly limited to JS/TS, Java, and associated languages. 120 is fine for most use cases; I've only seen 80 work in Go, but that one also has unwritten rules that prefer reducing indentation as much as possible; "line-of-sight programming", no object-oriented programming (which gives almost everything a layer of indentation already), but also it has no ternary statements, no try/catch blocks, etc. It's a very left-aligned language, which is great for not unnecessarily using up that 80 column "budget".
      • anilakar 1y ago
        But a 49" ultrawide is just two 27" monitors side by side. :-)
        • account42 1y ago
          Better yet, its three monitors with more reasonable aspect ratios side by side. 16:9 is rarely what you want for anything that is mainly text.
      • guenthert 1y ago
        Obviously 100 is the right choice. https://en.wikipedia.org/wiki/Line_length#cite_note-dykip-8 https://en.wikipedia.org/wiki/Line_length#cite_note-dykip-8
    • setopt 1y ago
      It’s tricky to find an objective optimum. Personally I’ve been happy with up to 100 chars per line (aim for 80 but some lines are just more readable without wrapping). But someone will always have to either scroll horizontally or wrap the text. I’m speaking as someone who often views code on my phone, with a ~40 characters wide screen. In typography, it’s well accepted that an average of ~66 chars per line increases readability of bulk text, with the theory being that short lines require you to mentally «jump» to the beginning of the next line frequently which interrupts flow, but long lines make it harder to mentally keep track of where you are in each line. There is however a difference between newspapers and books, since shorter ~40-char columns allows rapid skimming by moving your eyes down a column instead of zigzagging through the text. But I don’t think these numbers translate directly to code, which is usually written with most lines indented (on the left) and most lines shorter than the maximum (few statements are so long). Depending on language, I could easily imagine a line length of 100 leading to an average of ~66 chars per line.
      • fmbb 1y ago
        > the theory being that short lines require you to mentally «jump» to the beginning of the next line frequently which interrupts flow, but long lines make it harder to mentally keep track of where you are in each line. In my experience, with programming you rarely have lines of 140 printable characters. A lot of it is indentation. So it’s probably rarely a problem to find your way back on the next line.
      • forrestthewoods 1y ago
        I don’t think code is comparable. Reading code is far more stochastic than reading a novel. For C/C++ headers I absolutely despise verbose doxygen bullshit commented a spreading relatively straightforward functions across 10 lines of comments and args. I want to be able to quickly skim function names and then read arguments only if deemed relevant. I don’t want to read every single word.
    • layer8 1y ago
      100 is the sweet spot, IMO. I like splitting long text as in log statements into appropriate source lines, just like you would a Markdown paragraph. As in: logger.info( "I like splitting long text as in log statements " + "into ” + suitablelAdjective + " source lines, " + "just like you would a Markdown paragraph. " + "As in: " + quine); I agree that many formatters are bad about this, like introducing an indent for all but the first content line, or putting the concatenation operator in the front instead of the back, thereby also causing non-uniform alinkemt of the text content.
      • saagarjha 1y ago
        This makes it really annoying to grep for log messages. I can't control what you do in your codebase but I will always argue against this the ones I work on.
        • layer8 1y ago
          I haven’t found this to be a problem in practice. You generally can’t grep for the complete message anyway due to inserted arguments. Picking a distinctive formulation from the log message virtually always does the trick. I do take care to not place line breaks in the middle of a semantic unit if possible.
          • saagarjha 1y ago
            Yes, I find the part of the message that doesn't have interpolated arguments in it. The problem is that the literal part of the string might be broken up across lines.
            • bogomog 1y ago
              And to add to this, you rarely need to read a log message when just visually scanning code, its fine going off the screen.
      • maleldil 1y ago
        Nitpick: this looks like Python. You don't need + to concatenate string literal. This is the type of thing a linter can catch.
  • jitl 1y ago
    every editor can wrap text these days. good ones will even indent the wrapped text properly
    • hulitu 1y ago
      > every editor can wrap text these days. could. Yesterday notepad (win 10) just plainly refused.
      • jitl 1y ago
        Windows is so weird
    • giveita 1y ago
      Thats a slippery slope towards storing semantics and displaying locally preferred syntax ;)
      • jitl 1y ago
        I prefer storing plain text and displaying locally preferred syntax, to a degree. With some expressions, like lookup tables or bit strings, hand wrapping and careful white space use is the difference between “understandable and intuitive” and “completely meaningless”. In JS world, `// prettier-ignore` above such an expression preserves it but ideally there’s a more universal way to express this.
      • NL807 1y ago
        And the bikeshedding has begun...
        • virtue3 1y ago
          was going to say the same thing. Boy that was fast.
        • giveita 1y ago
          What's the nuclear reactor in this analogy?
  • elevation 1y ago
    Formatters eliminating long lines is a pet peeve of mine. About once every other project, some portion of the source benefits from source code being arranged in a tabular format. Long lines which are juxtaposed help make dissimilar values stand out. The following table is not unlike code I have written: setup_spi(&adc, mode=SPI_01, rate=15, cs_control=CS_MUXED, cs=0x01); setup_spi(&eeprom, mode=SPI_10, rate=13, cs_control=CS_MUXED, cs=0x02); setup_spi(&mram, mode=SPI_10, rate=50, cs_control=CS_DIRECT, cs=0x08); Even if we add 4-5 more operational parameters, I find this arrangement much more readable than the short-line equivalent: setup_spi(&adc, mode=SPI_01, rate=15, cs_control=CS_MUXED, cs=0x01); setup_spi(&eeprom, mode=SPI_10, rate=13, cs_control=CS_MUXED, cs=0x02); setup_spi(&mram, mode=SPI_10, rate=50, cs_control=CS_DIRECT, cs=0x08); Or worse, the formatter may keep the long lines but normalize the spaces, ruining the tabular alignment: setup_spi(&adc, mode=SPI_01, rate=15, cs_control=CS_MUXED, cs=0x01); setup_spi(&som_eeprom, mode=SPI_10, rate=13, cs_control=CS_MUXED, cs=0x02); setup_spi(&mram, mode=SPI_10, rate=50, cs_control=CS_DIRECT, cs=0x08); Sometimes a neat, human-maintained block of 200 character lines brings order to chaos, even if you have to scroll a little.
    • lambdaba 1y ago
      I agree, I'm very much against any line length constraint, it's arbitrary and word wrapping exists.
    • IlikeKitties 1y ago
      I'm suprised. I find the short-line version to be much better.
    • growse 1y ago
      //nolint
      • bloak 1y ago
        /* clang-format off */
    • VBprogrammer 1y ago
  • tsimionescu 1y ago
    I am at the opposite end. Having any line length constraints whatsoever seems like a massive waste of time every time I've seen it. Let the lines be as long as I need them, and accept that your colleagues will not be idiots. A guideline for newer colleagues is great, but auto-formatters messing with line lengths is a source of significant annoyance.
    • Cthulhu_ 1y ago
      > auto-formatters messing with line lengths is a source of significant annoyance. Unless they have been a thing since the start of a project; existing code should never be affected by formatters, that's unnecessary churn. If a formatter is introduced later on in a project (or a formatting rule changed), it should be applied to all code in one go and no new code accepted if it hasn't passed through the formatter. I think nobody should have to think about code formatting, and no diff should contain "just" formatting changes unless there's also an updated formatting rule in there. But also, you should be able to escape the automatic formatting if there is a specific use case for it, like the data table mentioned earlier.
  • jghn 1y ago
    I’d agree with you except for the trend over the last 10 years or so to set limits back to the Stone Age. For a while there we seemed to be settling on somewhere around 150 characters and yet these days we’re back to the 80-100 range.
• forrestthewoods 1y ago
  I’ll go a step further. I’ve never understood why people care so much about the linter. Just let people write code and don’t worry about the linter. I don’t need to fight a linter which makes my code worse when I could just write it in a way that doesn’t suck. I promise it’ll be fine. I’m too busy doing actual software engineering to care if code is not perfectly formatted to some arbitrary style specification. I feel like style lingers are horseshoe theory. Use them enough and eventually you wrap back around to just living without them.
  • pletnes 1y ago
    Some linters find issues you care about. Forgotten print statements or confusing indentations come to mind. I’ve worked with people who easily forget, and I’m one of them myself.
    • deleted 1y ago
      [deleted]
  • jwilber 1y ago
    But what’s the issue? Setting lint rules is one and done - running pre-commit can be made automatic?
  • skinner927 1y ago
    The point of linters is so the code looks the same regardless of who wrote it. This way it’s easier to read. Some people have horrible style and linters really help. I find linters make me faster. Sometimes I’m feeling lazy and I just want to pump out a bunch of lines of ugly code with mappings poorly formatted, bad indents, and just have it all synched up when I save.
    • carlosjobim 1y ago
      I see no reason to accommodate to worthless programmers who aren't able to read or format the code that's sent to them. They can lint it themselves if they want.
• garbagepatch 1y ago
  > just make a choice Now you are bikeshedding. Just go with the defaults.
  • wartijn_ 1y ago
    Which defaults? The programming languages I’ve worked with don’t have defaults for everything related to formatting. Editor defaults don’t work, since not everybody uses the same editor. So you have to make a choice somewhere.
    • swiftcoder 1y ago
      A lot of (relatively) recent languages do have defaults. Go and rust both come with an auto formatter out of the box, and defaults that are sane enough to just run with
      • wartijn_ 1y ago
        Ah yeah, in those cases it is possible to just use the defaults. Come to think of it, I have worked with Deno, which comes with a formatter (and linter and testing library) and I’m a fan. Saves a couple of dependencies, some config files and a bit of mental overhead when creating a new project.
    • stavros 1y ago
      I guess the GP means "use an opinionated formatter", I agree with both of you.
    • genericspammer 1y ago
      Please inform me what the defaults are for Java, C#, C++, C, Bash and Python?
      • sfn42 1y ago
        As far as C# goes there's `dotnet format`. You can use it as is or provide an `.editorconfig` file to customize it.
• smokel 1y ago
  I've never understood why we still look at the plain text representation of code, and not a visualization of the code that makes more sense. Note that, in my mind, this visualization is not automatically generated, but lovingly created by humans who wish their code to be understood by others. It is not separate from the code, as typical design documentation is, but an integral part of it, stored in metadata. Consider it an extension of variable and function naming. There is of course "literate programming" [1], but somehow (improvements of) that never took off in larger systems. [1] https://en.wikipedia.org/wiki/Literate_programming https://en.wikipedia.org/wiki/Literate_programming
  • jraph 1y ago
    > I've never understood why we still look at the plain text representation of code, and not a visualization of the code that makes more sense. I suppose this is because nobody has been able to create good tooling for it (the visualization itself, the efficient editing, etc). You'll have to deal with the text version of it at some point if not all tools that we rely on get a version for the new visualization. Another hypothesis is that it might not matter this much that we work with text directly after all. > Note that, in my mind, this visualization is not automatically generated, but lovingly created by humans who wish their code to be understood by others. If you allow manual crafting there, I suspect you'll need some sort of linting too.
    • seer 1y ago
      Um isn't that what Lisp and its children / siblings have been all about. I've written a bit of Closure it has a very clear idea that code is data and data is code. Your code is trivially serializable in your mind and by various tools, and because it is lisp - it all kinda makes sense. I really wish we lived in a universe where a lisp became the lengua franca of the world instead of javascript, as almost happened with Netscape, but alas ...
      • jraph 1y ago
        The "code is data" aspect of lisp seems orthogonal to how code is still written as text, and btw lisp is still written using text. You still need to indent all these parentheses. Virtually all programming languages are parsed into ASTs, and these ASTs can be serialized back. This is what formatters/"prettifiers" usually do. Did I miss something?
• AdieuToLogic 1y ago
  > I've never understood why people care so much about the linter settings. Source code formatting programs are not the same as lint[0] programs. The former rewrites source code files such that the output is conformant with a set of layout rules without altering existing logic. The latter is a category of idempotent source code analysis programs typically used to identify potential implementation errors within otherwise valid constructs. Some language tools support both formatting and source code analysis, but this is an implementation detail. 0 - https://en.wikipedia.org/wiki/Lint_(software) https://en.wikipedia.org/wiki/Lint_(software)
  • stavros 1y ago
    Right, but it's obvious they meant "formatter".
    • _mu 1y ago
      Why build understanding when you could be pedantic?
      • AdieuToLogic 1y ago
        > Why build understanding when you could be pedantic? Why try to share knowledge and give people an opportunity to learn the difference between two distinct concepts when they may not be aware of same? Is that pedantry or an attempt to "build understanding"?
  • kristopolous 1y ago
    Formatters, if you want to be specific, are even worse. They slyly add git noise and pollute your audit trails by just going through and moving shit around whenever you save a file. And sometimes, they actually insert bugs - string formatting errors are my favorite example. It's for people who think good code is a about adhering to aesthetic ideologies instead of making things documented and accountable. This is most noticeable in open source contributions. Sometimes I'll get a pull request with like 2 lines of change and 120 lines of some reformating tool. You think I accept that? It's not a good idea
• psychoslave 1y ago
  I don't care that much about the specific retained options (though my own gusts of the day are obviously the best taste ever in the whole existence of universe) but having a common linter setting to prevent the noise in every damn PR is a must have. Yes both git and all these PL are actually damn stupid to take lines at face value instead of something more elegant like Ada does. In my 20+ year career I've been proposed only once a project that involved Ada. It's hard to come with something elegant and efficient. It's even harder to make it reach top tiers global presence, all the more when the ecological niche is already filled with good enough stuff.
• socalgal2 1y ago
  some settings have advantages. For example, trailing commas on tables [ 'apple', 'banana', 'orange', ] has an advantage over [ 'apple', 'banana', 'orange' ] Because adding a new line at the end of the table (1) requires editing 1 line, instead of 2 (2) makes the diffs in code review smaller and easier to read and review. So a bad choice makes my life harder. The same applies to local variable declarations. Sorted lists (or sorted includes) is also something that makes my life easier. If they're not sorted then everyone adds their new things to the end, which means there are many times more merge conflicts. sorted doesn't mean there are zero but does mean there are less than "append to the end". So, just like an auto-formatter is there to save time, don't waste my time by not sorting where possible. Also, my OCD hates inconsistency. So [1, 2, 3] {a, b, c} Is ok and [ 1, 2, 3 ] [ a, b, c ] Is ok but [1, 2, 3] { a, b, c } Is not. I don't care which but pick ONE style, not two styles!
  • huflungdung 1y ago
    That isn’t ocd.
  • yes_man 1y ago
    The problem is when 2 people with same level of enthusiasm for linter rules but opposing views collide. If there’s nothing more impactful you could be solving and spending energy and time on than arguing those linter rules, then it’s time to question where the project is at and where is it going. And if there is something more important, then instead of of micro-optimizing the rules when there is strong disagreement it’s probably best if one of the parties takes the high road and lives with it so you can all focus on what matters.
    • vbezhenar 1y ago
      I guess that's one reason why opinionated tools like prettier or gofmt are popular. They made all the choices for you, they don't have configurable knobs, so you just learn to live with it.
      • 1y ago
• torginus 1y ago
  The problem is that tools like ESlint often come with highly opinionated rules that might not even be applicable all of the time (leading to me having to manually turn them off via annotations) And there's no centralized idea on best practices.
  • __alexs 1y ago
    eslint is slow and has terrible UX. Use Biome instead.
    • torginus 1y ago
      Hi, I'm you from the future. Biome is slow and has terrible UX. Use Tokamak instead (/s)
      • __alexs 1y ago
        Biome has several advantages that make this future unlikely and evidence from similar attempts in other languages seems to support their direction. Such pessimism is unwarranted.
  • HelloNurse 1y ago
    And best practices depend. Recently, I discovered that the ruff linter for Python doesn't like the assert statement, because since it does nothing in "optimized" mode it isn't reliable. But such complaints about unit tests are not particularly useful.
    • mr_mitm 1y ago
      Rule S101 [1] is not in the default settings. If you choose to enable it, you have the possibility of disabling it for your tests like so: [tool.ruff.lint.per-file-ignores] "tests/*" = ["S101"] (Besides, this was about formatting, not linting, but I realize it's related.) [1] https://docs.astral.sh/ruff/rules/ https://docs.astral.sh/ruff/rules/
  • Cthulhu_ 1y ago
• einpoklum 1y ago
  If you ride a bike every day, bike sheds are rather important. If you write and edit and read and search code every day, code formatting is rather important.
  • genericspammer 1y ago
    The point is that in the large picture there are many much more important topics with higher impact to focus on. The company wont make much more money by having consistently formatted code, compared to putting that energy towards new features.
  • onion2k 1y ago
    Consistency is important because it helps you pattern match. What the pattern is doesn't really matter.
  • DonHopkins 1y ago
    You're missing what the bike shedding metaphor is about. It's not about having bike sheds or not, it's about coloring bike sheds, which every day bike riders in their right mind really don't give a shit about, because it doesn't affect their life in any tangible way.
    • Moomoomoo309 1y ago
      No, the original metaphor is they were planning to build a nuclear reactor and they spent significantly more time than expected on the details of the bike shed because it was simple to understand and change, unlike the details of the reactor which were complex and required expertise and had lots of constraints. Who cares what color the bike shed is, we're building a nuclear reactor here!
      • anonymars 1y ago
        "Sigh, this guy is pedantically missing the...oh" Took me a sec, but well played
      • einpoklum 1y ago
• deadbabe 1y ago
  It’s more of a political thing. Controlling the linter is the first step of kingdom building.
• Cthulhu_ 1y ago
  But (at least for a long time), "run the linter automatically" wasn't available, not until Go's gofmt put the idea into people's heads that they could leave it to a tool. I think there were some formatting tools before then, but e.g. jslint/eslint had a lot of gaps which I unfortunately ended up pointing out in code reviews a lot. Which was nitpicking / bikeshedding, in hindsight.
  • memset 1y ago
    Interestingly, for over 30 years, C has had “indent” https://www.gnu.org/software/indent/manual/indent.html https://www.gnu.org/software/indent/manual/indent.html
    • psychoslave 1y ago
      What are the defaults, though, as not everyone seems to agree with GNU coding style? >First off, I’d suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it’s a great symbolic gesture. https://www.kernel.org/doc/html/v4.10/process/coding-style.html https://www.kernel.org/doc/html/v4.10/process/coding-style.h...
• scott_w 1y ago
  > It's so obviously bikeshedding I think you just answered your own question ;-)
• rs186 1y ago
  That is true if a set of good linting rules are set up, those that help discover errors or other code smells which are valid issues in 99% of cases, or pure formatting rules when there is no "correct" thing to do. Linting becomes a problem when it is opinionated and has questionable rationale to begin with, and stands in your way instead of help you catch issues. Nobody should be fighting linting rules, but sadly that's what often happens. See my other comment: https://news.ycombinator.com/item?id=45166670 https://news.ycombinator.com/item?id=45166670
• worldsayshi 1y ago
  I agree. Linters are one of the more frustrating aspects of modern dev. It's of such little relevance and yet it takes up a sizeable portion of my time when I'm going for a merge. Many editors/language combinations don't give automatic linting out of the box and when they do I can bet that the rules they infer is different from what the CI pipeline infers.
• xpe 1y ago
  I suggest rephrasing as a series of question: 1. Assuming at least one person who cares about linter settings isn't utterly confused or moronic, what are their self-described reasons why they care? People's work styles, brains, and even sensory perception differ in some important ways! 2. As freedom-loving developers [1] who want to make our own choices to help our own styles of work, why should we even have to care about "enforcing" one standard for something that isn't really necessary? This one-standard-per-project thing is a downstream result of a design decision upstream (storing source code as plain text). 3. How should we design languages going forward? This brings the conversation back to top-level post (which is why we're here -- to think about what languages could be, not to rehash tired old debates, after all): how can we take what we've learned and build better languages -- perhaps ones where the primary source of truth for source code is not plain text? [1] Slightly tongue-in-cheek. It is one thing to want to have freedom to do our jobs well, it is another thing to turn this into advocacy an overarching system such as a political philosophy or various decentralized financial mechanisms and so on. Here, I'm merely referring to the "let me do my job in the way that actually works for my brain" sense.
• sotix 1y ago
  A strong reason I enjoy Rust for collaboration is that it's so opinionated, it forces people to focus on solving real problems. I agree that bikeshedding over ES Lint and Prettier configs are not a strong use of time.
• schneems 1y ago
  I learned to love rustfmt but there’s one thing that bothers me: There’s a few times where there are two ways to do something like a one line closure can omit the curly brackets, but multi line closures cannot. Rustfmt prefers to remove those brackets when it can, but I prefer to keep them, which makes editing the code faster since I don’t have a syntax error if I suddenly need a second line. I can still live with it. And I like the clean, minimal version when I don’t have to edit. Just adding that “style” can have impact beyond how it looks involving ease of editing. And it stinks when your preferences clash with the community.
• Bender 1y ago
  I can see why people prefer particular styles so it's easier to read but on that note with Perl it was just perltidy flags. I can run perltidy on any code anyone here writes and it's easy for me to read, then I can pass it back to whomever and they can run perltidy with their favorite flags and it's easy for them to read. It probably doesn't quite work this way with all languages. I would imagine python being less flexible in this regard.
• vidarh 1y ago
  Because I spent the vast majority of the time I spent on code reading it, and the layout matters to me in terms of how much time it takes for me to read code. Yes, I can get used to other layouts, but that by no means means all layouts are equal to me in terms of how readable they are, and how well things stand out when they should, or blend in when they should. I recognise this isn't the case for everyone - some people read code beginning to end and it doesn't matter how its laid out. But I pattern match visually, and read fragments based on layout, and I remember code based on visual patterns. Ironically, because I have aphantasia, and don't visualise things with my "minds eye", but I still remember things by visual appearance and spatial cues better than by text.
  • godshatter 1y ago
    That's interesting. I also have aphantasia and I seem to be the only one around where I work that cares one bit about visual presentation. I suspect it's because people with aphantasia have to rely on waiting for visual recognition to happen so often that we get good at it and rely on it more. I'm also known for figuring out a problem and jumping to the exact file and area in the code that's causing it immediately where others apparently have to read through the code again to find it. I just remember it's maybe 2/3 the way through the file and just past that big switch statement and has a one-liner comment above it and has a distinctive shape. For me, indenting with tabs and aligning with spaces helps me find the code that I'm looking for as does adequate whitespace and a color syntax highlighting editor. Aligning things with distinct columns where it makes sense helps a lot, too.
    • vidarh 1y ago
      Yeah, all of this matches my experience too.
• duxup 1y ago
  I'm in the same boat. I have not run into any situations where someone's choice on formatting was bad enough that I couldn't read the code so ... just pick a format / standard and let's go. I'll get used to it if I'm not already.
• patwolf 1y ago
  I went through this on a few projects, and what surprised me the most was that some devs have very strong opinions about import ordering. I mostly rely on the IDE to manage imports, and most the time they're not even visible. We had to add a lot of prettier rules to get import orders just right.
• kolme 1y ago
  I did that when I was young and naive. I'll tell you why I did it. I thought I was very smart. Like, really really smart, maybe the smartest programmer in the team. And as such my opinion was very important. Maybe the most important opinion in the team. Everyone had to listen to it! That is all. Also, I was wrong.
  • robertlagrant 1y ago
    > Also, I was wrong. This is probably the only useful takeaway, but can you explain why you were wrong?
    • kolme 1y ago
      Yes, I was wrong on several levels. First and foremost I was wrong thinking that I was smarter than others — that's not even how intelligence works. Second I was wrong being so stubbornly pro-tabs / anti-spaces (for example). It doesn't make that much of a difference, so there's no point in being so passionate about it. And third I was wasting everyone's time (and my persuasion powers) by not choosing my battles more wisely. My suggestion would be nowadays: let's choose a popular style guide, set up a linter and be done with it.
  • _ea1k 1y ago
    I feel like a _lot_ of us have been through this cycle. It is so easy to think we've discovered the one true way to do something. Time and experience often tell us that it was just one of many, and maybe not even the best one of many.
• ParetoOptimal 1y ago
  > I promise after a week you'll just get used to whatever format your team lands on. Arthur Witney formats like this: C vt[]="+{~<#,"; A(*vd[])()={0,plus,from,find,0,rsh,cat}, (*vm[])()={0,id,size,iota,box,sha,0}; If your code was formatted automatically like that, do you think you'd get used to it after a week? My point is there is meaning of how code is formatted and there is an effect on understanding for certain people. I think that at a certain point of "reasonable" and for most "normal" people your statements hold true, but I don't want anyone to think that every person caught up on formatting is just doing it for bike-shedding or other trivial reasons. I don't know what is actionable if what I say is true, but it feels important to say.
  • fallpeak 1y ago
    The unreadability of that example has approximately nothing to do with code formatting, which is generally understood to refer to modifying the textual representation of the code while leaving the actual logic more or less unchanged. Can you propose some alternative whitespace or indentation scheme which would make that example significantly more readable?
• yoyohello13 1y ago
  Same! I have no patience for these kind of arguments about formatting. I don't care that you don't like what the formatter does, it isn't about you. I've written code in several different languages over the years and the main take away is that I can get used to reading anything. It's so important to pick a standard and follow it. As long as that standard is somewhat sane I couldn't care less what the actual standard is. Another argument that is a pet peeve of mine is significant white-space vs curly braces. It literally doesn't matter. We often get new Python developers coming from a C# background and the amount of bitching about curly braces is so annoying. Just learn the language bro, it's not that hard.
• mhh__ 1y ago
  Some styles can actively make some people less productive though e.g. I really try to avoid allman braces because I can work a lot better with denser (for a certain definition of dense code) This, however, usually doesn't effect me if the official format for a project is one way or the other because [drumroll] I just format my tree differently and then format to the official style when I push.
• anbotero 1y ago
  Those that complain: I've worked with several Development Leads to actually define these. After the initial adjustment period, everybody's local environment setup properly: No one ever spent time reviewing style and formatting on Pull Requests. Just decide as a team, auto-apply if possible (less than 5 seconds for big changes), enforce, and be done with it. Stop wasting everybody's time because after weeks you cannot make your mind on it and also don't tell your team/Lead about it.
• VonGallifrey 1y ago
  > just make a choice, run the linter automatically and be done with it. Most people probably do this. These types of discussions (probably) come up when someone else made the choice and other people also need to adhere to this choice. This is important for teams, but sometimes big egos don't want these choices made for them.
• aequitas 1y ago
  It’s very simple: format code to a standard. Preferably the language default formatting. But it must be a standard that can be auto formatted to with a tool. Now when someone doesn’t like that standard, they can auto format from that standard to one of their liking for local development and back again to the project standard for pushing to the project. This can even be done automatically with gitattributes during checkout and commit. But without strictly enforcing a autoformatable standard this is not possible and you end up with bikeshedding.