my car is absolutely a boat if you put a boat motor on the back of it and waterproof it

it’s basically a TUI notepad. It’s there, it does one job and that’s all there is to it

That’s what the people who like it like about it.

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.

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 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”.

`/* 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()) }`

OH CAPTAIN MY CAPTAIN

kinda feels like they’re trying to emulate server-side templating with shit like django and thymeleaf

merge commits that catch my feature branches up to main

You’d be squashing those when you merge back down into main anyway, no?

This way I can wreck their shit instead! Enjoy debugging this one Tim, you obtuse bastard!