Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
I slightly disagree with No duplication of code. It's a good rule on general, but sometimes its better to have duplicate code if it keeps you from bad or premature abstractions. Readability over DRYness.
Well written Jan, to add few helpful quotes on top of this:
"A little copying is better than a little dependency." go-proverbs.github.io/
"duplication is far cheaper than the wrong abstraction." sandimetz.com/blog/2016/1/20/the-w...
it is common to see intermediate level developer writing complex code with high readability/maintainability cost just for the sake of DRYness
Yes Jan that's correct. Too much abstraction is also bad. Especially such abstractions which change every time you introduce new feature. At the end of day, it's you who should be aware of various scenarios while writing any abstraction. I always suggest people to write duplicate code for first and second time, for the third time if same thing arises, we can start refactoring. You can read my blog on Technical Debts and Refactoring.
The purpose of all of these rules is readability. There is nothing less readable than having a code base with needless needless amounts of functions and needless amounts of abstraction.. This notion that functions should only be 6 lines of code is silly and counter productive. As one of the other commenters mentioned, readability is most important.
Minimal number of lines of code, classes, functions etc. Less code means less headache, less bugs and less maintenance cost.
My purpose is to tell people not to write 100s of lines of code in the same function. At the end Readability and uniformity is what matters and same I am trying to convey here.
Less code does not mean less headache. Better to be more verbose and readable then too terse.
I'd say leaving code in comments is okay if it's accompanied with a comment to tell when to use the code. For example, you could have correct code in a comment but you have to use some kind of workaround while waiting the library maintainer to fix some bug in dependency. And you cannot code automatic switching because you're not sure which version will contain the fix.
However, in many cases you should prefer having a config variable to activate old or new logic for that part, even if the config were called CONFIG_WORKAROUND_FOO_BUG_53663.
But why would you leave a code like that and why do you need to design your software such as you need to comment and uncomment your code for different features. I can understand it is okay for testing but I don't think it is a good approach to follow for production ready code
I was thinking a case where logically you should use some code but due a problem in a library that you're using, you have to use some kind of workaround (with possibly worse runtime performance).
However, until the library maintainer has fixed the problem you cannot be sure if the correct code you are currently thinking is the actual final implementation because it could turn out that the library maintainer cannot fix the current API due backwards compatibility issues and you have to use a newly introduced function to get the fixed behavior for the use case you need. And if you use programming language such as C you cannot keep the "probably soon to be implemented code using currently non-existing API" visible to compiler so you have to hide it from the compiler. Putting the code in comments is one common way to do it.
Of course, you can also keep track of such future changes somewhere else but the actual source code. It really depends on how the whole project is implemented.
Great post, thanks for sharing. Another good practice might be to adopt an upper limit of characters for the function names. If your function name is to long that indicates that you should probably have to break it down.
@sp1thas thanks. Yes I will update the blog. I need to add more points to it.
Also proper line breaks, like those use by Prettier on long lines. Avoids having to scroll right and left to read reminder of statements. Having proper structured code goes a long way on readability as well.
Care to elaborate on the Magic Word thing? I don't get it. Also shouldn't it be >= instead of >?
Improved thanks. Magic number is nothing but using direct number in code:
if(name.length()>12){ ----} // here using 12 directly is bad.
Instead we should use
MAX_NAME_LENGTH=12;
if(name.length()>MAX_NAME_LENGTH) { ------ }
imo its typo, it should look like this -->
if(age >= MINIMUM_AGE_FOR_VOTING) "eligible for voting"You were absolutely correct while saying to duplicate the code instead of adding too many abstraction level. As not only it makes code complicated for others to read but also a developer would find it little bit tricky to make changes in the same. And also person should avoid duplication in the 3rd time - not necessarily in the 2nd time with a bit of abstraction. A good article though with a perspective of clean coding !!
Thanks for uploading this kind of content.
I think there is a typo. You used "Varibale" instead "Variable". Is this an intended one?
Improved it. Thanks
Still many "varibale" typos in the article - try find to locate all.
hi, want to know more