Formatting, style rules and code documentation aside, I try to get rid of anything that adds cognitive load, no matter how tiny that load is. Braces, nested structures ifs and elses and other control structures can add to that. I try to get my logic as "flat" (indented on a single level) as possible.
If there is a bunch of ifs and elses in a method, I refactor them out into smaller private methods with self-describing names. If those are still too big I repeat the process until I have small methods that pretty much do just one thing each.
I try to keep methods brief. They should not span over the height of one editor page.
I try to keep classes small. I guess if a class grows beyond 500 to 600ish lines it's probably time for a split.
If an if-condition is complex then I split the condition out in a separate method with a self-describing name.
I often do that even with simple if-conditions, because sometime's it's not clear why we do:
if (sku.endsWith("X")
but the following is much clearer and doesn't require asking any questions:
if (isRetiredProductSku(sku))
If a method / function has too many arguments (3 is already scratching the limit) then I try to refactor so:
Either most of the argument values are stored as properties if possible (and if it makes sense)
Or the arguments are consolidated in a single configuration or context object, where grouping them together makes sense
Using the builder pattern can also help with reducing the amount of method arguments
That's... just off the top of my head at the moment 😁
Hi Thomas, I loved your small example. This is exactly why I was fighting for in my ex-team, "yeah, but I won't create a function for only one line of code"... Stubborn junior devs, they've made me loss a few hair ahah.
I guess your former colleagues were still OK with adding comments in case of especially obscure logic?
So it's either this:
// Retired product SKUs end with X
if (sku.endsWith("X"))
or that
if (isRetiredProductSKU(sku))
The second version is actually more maintainable. The rules for detecting a retired product SKU might change over time. In case of the first version with the comment it would be necessary to update both the code and the comment, and usually the latter one is forgotten.
Anyway, for people who are really allergic to writing extra functions, here's another variant that is also more readable:
const isRetiredProductSku = sku.endsWith("X");
if (isRetiredProductSku) {
...
}
I think sometimes the best you can do in a team like that is to lead by example in your own contributions, and eventually they start appreciating the readability of the code you write and adopt your style 🤷♂️
I totally agree with you. Yeah, I've tried to lead by example, but that didn't work either. But thanks to that my manager moved me in another team, much much better! That was such an experience, professionally: working with really bad code, and personally: mental health ahah.
I think they didn't listen because I'm younger, by ego I suppose, I don't really know but that's bad for them.
We have to let your ego aside and listen to people to progress :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Formatting, style rules and code documentation aside, I try to get rid of anything that adds cognitive load, no matter how tiny that load is. Braces, nested structures ifs and elses and other control structures can add to that. I try to get my logic as "flat" (indented on a single level) as possible.
If there is a bunch of ifs and elses in a method, I refactor them out into smaller private methods with self-describing names. If those are still too big I repeat the process until I have small methods that pretty much do just one thing each.
I try to keep methods brief. They should not span over the height of one editor page.
I try to keep classes small. I guess if a class grows beyond 500 to 600ish lines it's probably time for a split.
If an if-condition is complex then I split the condition out in a separate method with a self-describing name.
I often do that even with simple if-conditions, because sometime's it's not clear why we do:
but the following is much clearer and doesn't require asking any questions:
If a method / function has too many arguments (3 is already scratching the limit) then I try to refactor so:
That's... just off the top of my head at the moment 😁
Hi Thomas, I loved your small example. This is exactly why I was fighting for in my ex-team, "yeah, but I won't create a function for only one line of code"... Stubborn junior devs, they've made me loss a few hair ahah.
Ah how rude of them! 😆
I guess your former colleagues were still OK with adding comments in case of especially obscure logic?
So it's either this:
or that
The second version is actually more maintainable. The rules for detecting a retired product SKU might change over time. In case of the first version with the comment it would be necessary to update both the code and the comment, and usually the latter one is forgotten.
Anyway, for people who are really allergic to writing extra functions, here's another variant that is also more readable:
I think sometimes the best you can do in a team like that is to lead by example in your own contributions, and eventually they start appreciating the readability of the code you write and adopt your style 🤷♂️
I totally agree with you. Yeah, I've tried to lead by example, but that didn't work either. But thanks to that my manager moved me in another team, much much better! That was such an experience, professionally: working with really bad code, and personally: mental health ahah.
I think they didn't listen because I'm younger, by ego I suppose, I don't really know but that's bad for them.
We have to let your ego aside and listen to people to progress :)