The other day, I was watching this video of Robert Martin where he mentions the three symptoms to spot a bad code. And I couldn’t have agreed mor...
For further actions, you may consider blocking this person and/or reporting abuse
From experience the point number 3 is a huge source of problem. it tend to increase rigidity and fragility.
The thing is making code truly reusable is really difficult and costly. It require lot of experience, budget and commitment to make an API rather than just a program that solve a single problem. I speak of API on purpose. An API is fully backward compatible, fully documented (even if you don't like it), comes with tutorials and so on, deal with all corners cases (and has a defined and documented behavior for all). It also typically optimized for performance.
If you achieve that, your code is really usable, in particular you can reuse that code without severely affecting rigidity and fragility of your software.
On the contrary, reusing code without promoting such code as an API is sure to increase rigidity and fragility. Because the code is not truely generic. Because the code make some shortcut maybe, because the perf is not so great but was acceptable in the other use case. For lot of reason that code doesn't achieve the quality an API require. So it isn't really reusable.
I remember reading that a program something that managed to work if you provide it the right inputs/env typically cost 1 unit. This is like a prototype or a script to solve an issue. Then there is software. A program that is validated, handle lot of error case and is robust enough to do its job in variety of env. The cost of a program is 3 unit. Then there APIs, truely reusable code that is rock solid and you can struct and build software and programs on top of it. Like Java API, spring, hibernate or the win32 runtime. Because of all of this, the cost of an API is 10 unit.
I see that a great share of problems of rigidity and fragility come from tentative of reusability without really investing enough in it. when you aim for reusability, you should agree to pay the associated cost. Most of the time you or your management will not want to pay that cost. So it make much more sence to reuse existing and validated API, typically open source than try to make your own...
Thx for this perspective, I really like the analogies.
These are great points - but I have one question: How do you know you're writing bad code when you're writing it?
Despite having been writing code for like 15 years, I still sometimes find it hard to spot it when writing it. Yeah, I can go and try and change it later and I'll realize "oh this is kind of crap", but how do I prevent myself from writing it in that way in the first place?
My best solution so far has been TDD, but I'd be curious to hear if anyone has any other solutions :)
Robert Martin's Clean Code is a book that instructs a person how to see bad code, and how to fix bad code.
The book points out that these are skills that can be learned. And that they are difficult skills to acquire, so it is set up as examples and exercises to help learn the skills. For a wide variety of bad code (anti)patterns.
I have read somewhere before that the code for a feature or a module has to be written 3 times to get it right. :P
If you have to explain every detail of your code, and there are lots of questions, that code probably isn't very good and could be improved. Improve areas with the most questions and explaination. Even code that implements a complex mathematical algorithm should be easy to understand as long as others know the algorithm.
Yes, I agree. I even restrain myself from writing comments over the code to explain the code and try to refactor the code so that it explains itself.
Good article, but as a newbie React.js developer it seems that I can't set myself to follow these rules especially when it comes with state management in Redux, where there is a global store and many files are importing "actions" which they are responsible for updating it when they are called, but it doesn't mean that changing something is gonna be hard or the code is not going to be totally reusable, the architecture itself imposes this way of doing things, I hope that a professional React/Redux programmer is reading my comment and he/she has something to say or recommend some of the best practices...
Agreed, obviously. :) But you should add a social component and team play to it. From that point of view, "good code" is code most if not all devs in the team can easily work with, code that allows for finding and fixing bugs easily, code that helps implementing new features and delivering value fast. If in doubt I would prefer that approach and let the team come up with "clean code" definitions of its own. Code reuse is a good example: We've seen a load of situations where we started with "reusable" code moved into shared libs rather than (cough) copy-paste'ing a bunch of files around - and found ourselves ending up in considerable library versioning effort. Our solution to that, so far, has been making the team obviously do code reviews for each git pull request and make sure that, asides from being able to build and run code, at least two or three guys on the team accept that code as "clean enough". So far this works quite well. ;)
Yes, code reviewing and having a set of standard patterns for normal use cases is very important to have a clean code base, which is readable and maintainable by anyone in the team.
WordPress.
Code complete 2 is a good book
I have heard about that book at a lot of places. It's on my reading list. ;)