The conventional wisdom in software engineering advocates for breaking down code into loosely coupled functions, classes, and modules, among other ...
For further actions, you may consider blocking this person and/or reporting abuse
+1
Make it work
Then make it fast
Then make it pretty
As for WET. Totally agree. Write it once. If you have to write it again, grit your teeth and JFDI. The third time indicates this is a common pattern and needs to be abstracted.
pretty and fast are commonly two conflicting characteristics, so I'd suggest writing pretty and only if it's not fast enough, try to make it work fast
It depends on how you define pretty. I agree that it is probably not a good idea to abuse some esoteric language feature for speed (e.g. falsey values in JavaScript) as speed of understanding is more important than speed of execution on most cases.
To me, pretty means following the conventions of your language or organisation (PEP8 if writing python), using SOLID, use proper names for variables, functions and files, lay your code out consistently (e.g. either use semi colons or don't use them in js but don't mix them)
Anything you can do to reduce cognitive load without actually changing the logic is always worth the time invested.
You forgot the KISS principle 😁
The only person that has to understand the code is the coder. If I open a piece of code written years ago, it often goes like "OMG, I wrote this? What a mess!"
A problem can be solved in many different ways. We usually chose the path that feels comfortable. In knowledge and habit.
Beautiful written code becomes a habit in itself. Isn't that's true for everything we do? From cooking to gardening, painting and finetuning a car engine. And coding.
It's a beautiful satisfying hobby. Thanks for the thoughts @svemaraju
I agree with pretty much the entire article, but this line above is only true if you are 101% sure that nobody else is ever going to get involved in that project.
In the vast majority of cases, more than one person works on a codebase simultaneously, and you never know what might happen in the future.
Everybody has to understand the code, now and later.
My approach to code (but problem solving in general):
1) get my ideas out as quick as possible to accomplish my goal (docs, code, drawings, etc.)
2) refactor lightly (just enough for it to be coherent lol)
3) get feedback
Rinse and repeat.
That's why I find the Test Driven Development model super helpful. The first step is to write a test that fails, then make it pass as quickly as possible, then refactor. I believe the less cognitive load you have at each step, the more you can focus and deliver effectively.
Aiming for perfection on the first go all alone is crazy paralyzing, and unless you're a mind reader, is often so terribly wrong.
Good code to me is best created through a collaborative, iterative effort, between you and your team.
I'm overall agree with your point.
Just one thing is not convincing me:
This means VERY long reviews of the code that will results in:
WDYT?
Absolutely @ccarcaci . I am totally in favor of submitting the best version of the code for the PR. But the only reason I worded it like that is some times it is okay to keep the code as it is. It is not always an unmanageable mess.
Software development is a team game so I am definitely with you on involving your team to come up with design changes.
Thanks for reading and taking the time to comment your opinion!
I somewhat agree with this. I like the concept of it but I think some stuff should be moved into its own functions, classes etc in the same file just so you can easly come back the next day and still know what you wrote and dont need to spend an hour figuring it out.
You had me until the opening PR part.
For me it's normal to make "messy" code, but usually, I clean up a little before commiting it, then as I "finish" the PR I'm planning, I will clean it further.
As you finish whatever you're doing, then you would have a great view on where to extract something to a function or maybe you feel something might work, but is still messy.
People are not in my mind, so the only thing they will see is a mess. Similarly, as time passes I'll forget the finer details. Not only that, a long and messy something means you have to keep track of a lot of things... in other words, you're ignoring a lot of things because of the "magical 7 ± 2" people can keep in their "ram".
No, I am with you there. The reason I worded it like that is because readability is subjective. Sometimes I have seen people preferring code to be in design patterns they are familiar with. It is more readable for them. Sometimes it is the opposite. What I wanted to articulate here, and of course this is relative AF, is that sometimes it is okay to keep the code as it is. It is not always an unmanageable mess. But yes, if it is not up to your standard, then by all means clean it up. 🙌
Thanks for checking my post and taking the time to comment your opinion!
But what about people who name variables with some short letter that doesn't make sense at first, just to check if that function is gonna work before writing some long beautiful thoughtful name for the variable.
I do it all the time when I'm unsure if something won't work and things are complex. I just name variables and functions as short as possible just to discern while trying to make it work, and if it does work, then I prettify those names to be thoughtful so when I come back I know what I'm reading.
I just want to get the code working as quick as possible and then invest time in making it readable and performant. :)
Happy Coding
It's a very natural approach for me ever since I am coding.
Later when I push it to repo I clean it a bit.
Or you forget to clean it and leave it as is, to do some other stuff.
And it becomes interns job to fix it :D hahah
We all had humble beginning. It was never clear and lean in the start, we have to begin with baby steps, the learn how to walk and run (metaphorically for coding, of course).
Great tips, hopes your experience and tips can help more people.
Pretty well said!
Hmmm.... interesting