7 ms·
> replacing that with static analysis tools to remove such comments I dislike excessive usage of these kind of tools because not infrequently you end up making
by arp242 3y ago
> replacing that with static analysis tools to remove such comments
I dislike excessive usage of these kind of tools because not infrequently you end up making your code worse just to satisfy some dumb tool.
The real solution is just accepting that not all code needs to be like you would have written it yourself, and asking yourself "does this comment address anything that's objectively wrong with the code?" A lot of times the answer to that will be "no".
- renegade-otter 3y agoIt doesn't have to be excessive - it has to be reasonable. But I agree, outside of the strictly-enforced automation, just let it go and stop going "nitpick!" The less communication between devs during code reviews - the better. It's exhausting to be diplomatic to your coworkers asking them to change something. It's a minefield full of feelings and egos.
- a_cardboard_box 3y agoHuman reviewers can also demand your code be made worse. Sometimes, the choice is making your code worse to satisfy a dumb tool (software), or making your code worse to satisfy a dumb tool (person).
- arp242 3y agoAt least when it's a person it's someone you can talk to, reason with, compromise with, reasonably disagree with. Can't do any of that with software.
- kilotaras 3y agoMost tools have an escape hatch, see e.g. [0] [0] https://github.com/search?q=clang-format+off&type=code https://github.com/search?q=clang-format+off&type=code
- pjmlp 3y agoExample, clean code architecture astronauts.
- ddejohn 3y agoCan you elaborate?
- pjmlp 3y agoSome examples, https://serverlessfirst.com/emails/the-serverless-architecture-astronaut/ https://serverlessfirst.com/emails/the-serverless-architectu... https://stackoverflow.com/questions/404210/design-patterns-architecture-astronaut https://stackoverflow.com/questions/404210/design-patterns-a... https://www.google.com/amp/s/blog.codinghorror.com/it-came-from-planet-architecture/amp/ https://www.google.com/amp/s/blog.codinghorror.com/it-came-f...
- ddejohn 3y agoThanks for the links -- I understand the concept; I was asking more about specific examples related to "clean code". When I think of "clean code", I think "programming to interfaces" and "keeping domain/business logic separate from implementation details about HTTP/gRPC and database connection management, etc. Maybe I don't fully grok "clean code"?
- pjmlp 3y agoIn that case, https://qntm.org/clean https://qntm.org/clean Usually many architects tend to go overboard with interfaces for everything, repositories, data layers, hexagonal architecture, and whatever else is fashionable at conferences.
- delusional 3y agoIf your coworker demands you make the code worse, you'd have to imagine that it's a difference of style. They may believe you're making it better. At least in that case I'm satisfying the style of somebody else on my team. I view that as more valuable than satisfying some tool that nobody agrees with.
- bobthepanda 3y agoLinters are configurable, so the way they are supposed to be used is that you get your team to agree on one lint standard and shove it in the auto-linter so that reviewers can point to a higher authority instead of arguing in circles, pulling in other people onto their side, and wasting a bunch of time.
- deleted 3y ago[deleted]
- jacquesm 3y agoThis is exactly it. Most code reviewers make other people jump through hoops to force them to code 'their' way, whereas more often than not there are multiple ways to solve a problem neither of which is substantially better than the others. In the rare cases where there is a much better way of doing something there won't be anything to argue about, it will be obvious.
- gtirloni 3y agoI will often follow the codebase's way of doing things, even if I know a better way. I'll only push for the better way if I, or someone else, is willing to refactor the whole codebase. Last thing I want is to work on a codebase with N different ways to solve the same problem. That decreases productivity too much.
- jacquesm 3y agoThat makes sense. The problem is that it can be quite hard on large codebases to find such instances if they aren't routed through some library to avoid code duplication.
- RHSeeger 3y agoWhere I work, we have static analysis tools.. plus the ability to "override" (tell the tool to ignore this case) when we feel it makes sense ("I know what I'm doing here"). And then peer reviews to help make sure those overrides make sense.
- cratermoon 3y agoI worked with a programmer who littered his code with the incantations that disabled the linter, compiler warnings, static analyzer flags, and so on. His code passed all the automatic tools with nary a blip. Was it good code?
- RHSeeger 3y agoStatic analyzers are a tool. And peer reviews are a tool. And compilers are a tool. Being able to combine tools together (as I noted we did) helps you generate better code.
- dharmab 3y agoI use these tools but make sure to turn off any subjective checks in their configurations.
- ddejohn 3y agoI suppose it depends on what kind of tooling you specifically are talking about, but I strongly disagree in the case of Python. When you have such an "anything goes" language, it really helps to have a tool that enforces consistent style across a large group of developers. Unpopular opinion: I think individualism showing in code is a bad thing. Code should be textbook boring with as little personality showing as possible. This, of course, is due to my experience working in a department with ~40 developers. I work so much faster when I don't have to decipher "clever" code or somebody's personal style for how to line break their over-complicated comprehensions. It slows everybody down when there are 40 different dialects being "spoken". Homogenizing our code with linters and formatters means that any part of the codebase I jump into will look completely familiar and all I have to do is focus on the logic.
- Pannoniae 3y agoBut if all code looks like the same homogenized paste, then all expressivity from code is lost. Which is fine if you want to write the 68th CRUD app with developers who don't want to work on it, but seriously, it does wonders to productivity when everyone enjoys the tools they work with and the work itself. Forcing everyone to satisfy tools/code reviewers just kills all the joy from programming, so you get everyone to be mediocre.
- sodapopcan 3y ago...until someone has to work on someone else's overly clever "masterpiece". It's not so black and white and a tricky thing to get right and almost impossible to satisfy everyone's needs. In an ideal world, developers care more about how their program works more than how it is written. But ya, unfortunately most people are working on applications they don't care about, so they get overly creative with code and tools.
- Pannoniae 3y agoAlmost always, the "overly clever "masterpiece"" is unreadable because there is no proper documentation, not because the program itself is horrible. If you can't understand it because the writer didn't document it properly, shout at them for the lack of documentation, not for the unorthodox code style....
- Pannoniae 3y agoThe main thing is that static analysis tools, strict code style and whatnot put both a cap and a ceiling on the code quality. It will be a bit harder to write complete garbage, but at the same time, it has a negative impact on code quality because many of those rules are completely nonsensical and decrease code readability. Also, it puts a severe limitation on expressivity, which is a negative thing if you want your programmers to actually enjoy their job (which increases productivity...) Of course, if all you care about is the fungibility of your programmers, then having those overly strict rules completely makes sense, but if you want to produce a quality product, not so much.
- flippinburgers 3y agoWorking on codebases - like rails without rubocop - is not something I would like to consider. There is already too much variability in how people code.