`/* Gets CustomerEntity from customer repository by customer ID or throws a customer not found exception */
public CustomerEntity getCustomerEntityById(String customerId){ customerRepository.findById(customerId).orElseThrow(new CustomerNotFoundException()) }`
I had so many arguments with my team lead. He thought comments were an antipattern because that meant the code wasn’t expressive enough.
I understood where he was coming from, but a little hint here and there why the fuck the code is doing what it’s doing would’ve been nice.
Yeah, good code should explain the “what” without the need for comments. Good comments explain the “why”.
Generally, you can replace some comments with variable names or comment names. Which means you must already be in the habbit of extracting methods, setting new variables to use appropriate names, and limit context to reduce the name (Smaller classes and methods means shorter names can be just as expressive, because the context is clearer). It lowers the number of wtfs per minute you get reading code before you even need whole sentences to explain why things are done in a certain way, because the names can be a powerful hint.
But realistically, you end up needing comments for some things anyways.
You sound like an awesome co-worker. I love the way this is stated, and I’m 💯 in alignment
Also some parts of code are just going to smell, because of deadlines, other trade offs. For those it helps to have a comment to really highlight that bit of weirdness - the what and the why. If it is weird it should really “pop out” when you’re reading it.
I used to work with a guy who insisted his code was self explanatory, and then he’d nest loops 5 levels deep and give variables names like “thingyOne”.
I worked with a guy who was smart but “useless smart”. He was convinced that “code is self descriptive”, that is comments are not needed because the code speaks for itself. Well that is like saying DNA is self descriptive. Yes, I can sit there tracing the code, tracking the variables, etc or you could make a small effort to describe what is happening instead and save me a lot of time and risk missing subtle points.
That guy wasn’t in charge, I hope? That would not have passed code review with me at least.
I find that those people usually are the ones in charge.
It kind of feels like engineers look for simple solutions to what are ultimately complicated psychological questions sometimes.
I agree with your team lead wholeheartedly, but not for the reasons he would tell you. Comments should be used when code is too complex for the “name your variables nouns and your methods verbs” convention doesn’t communicate what the code does in a narrative fashion. Thing is, that level of complexity is definitely a code smell. You seem to be saying that clarifying comments are the solution, he seems to think that you should be able to rename vars and methods until the meaning is clear, and Im offering a third way: figure out why the fuck the code is doing something hard to understand and maybe try to unfuck it, then resort to comments if and only if that’s not possible. Remember that a code smell isn’t necessarily something that needs to be removed, it’s just a flag that says “let’s make double damn sure there isn’t a better way to do this before we do it this way”.
Yes, you don’t need to comment “n++” to say it is incrementing it but you should mention why you are starting with 1 instead of 0, etc. Boundary conditions are notoriously tricky and need to be documented. Then there are historical reasons that are NEVER obvious, “This function has to return -2 as a default because we’ve been calling it using X for years and it expects a -1 as the error…”
this function returns -2 as success and -1 as error
Thats exactly the kind of thing I’m talking about when I say to prioritize refactoring over comments. If you own the system returning the error code, drag it out of the 1970s and have it return an error object with some actual information in it instead. If you don’t own the system, wrap the error code in an enum that adds syntactic meaning or do a map of integer and exception and then return the mapped exception. The very last resort, after you’ve tried everything else, should be
return -1; //-1 indicates success
I’ve worked on satellite command and control software that is literally using a 1970s OS. The code is limited for historical reasons and you have to work with the structure you are given.
okay. doesn’t mean you still shouldn’t refactor or add a layer of abstraction where you can. we’re looking for a generalizable principle here and generalizable principles don’t assume that you’re working with satellites that are older than the dev.
Better yet. Only guy who knew the code retires/quits. The next guy who inherits the code finds out nothing was documented and it was all in the previous guy’s head. Next guy has to spend weeks analyzing the code, asking coworkers who shake their heads and buying beers after work to get the previous guy to help him.
When the the documentation is epic, but no one remembers to add why this repo even exists.
I’d like all files to have a big comment on top that says wtf this is, why is it, and roughly how it works. Bonus for ascii art.
[ ]
What was that comment I’ve seen a few times online…? Something like, “This function isn’t used, but commenting it out causes everything to break,” or similar. Anyone know what I’m talking about?
I like it when people rag on their own code in comments. “This line is a kluge but I can’t think of a better way to do it right now.” Comment is dated 10 years ago.
You might like this