5 ms·
I'm not sure what you mean with "reducing total code instructions" and "lean code", but I'm not sold on the idea of making code less readable which often happen
by ascar 8y ago
I'm not sure what you mean with "reducing total code instructions" and "lean code", but I'm not sold on the idea of making code less readable which often happens when you try to reduce code by being smart.
Reading code is mostly way harder than writing it, especially if you read code from someone else. Optimizing for readability is the game changer for maintainability.
* Use expressive function and variable names.
* Have clear consistent structure across your project(s).
* Use simple code where possible.
* Do not write one-liners that do multiple transformations. Each line should have one purpose.
* Document design decisions in code. Don't document "what" your code does, that should be readable by itself, but why you made the decision to do it like that.
* Documentation library style comments for complicated functions helps a ton to know what the function is supposed to do.
* Add tests that specify the expected behavior. This not only helps when changing code, but also when reading.
It's not readable code XOR documentation, it's both. Readable code is the "what", documentation is the "why". Even if the docs get outdated, the why can still be insightful.
Non of the above suggestions usually reduces code, but it will help everyone else, including future-you in 6-months, to work with your code.
- codebje 8y agoLess code should not mean either less readable code, or cleverer code. It should just mean ... less code. Using abstractions, removing dead code, refactoring to share common code paths, etc, all reduce the amount of code you have, and all typically increase the readability of your code. This doesn't seem at odds with your bullet list for maintainable code. A useful maxim is: working software is an asset, source code is a liability. More code means more maintenance cost, so accomplishing business outcomes with less code is good, to a point.
- austincheney 8y agoA simple rule is that more instructions mean more execution time and more people time. The first of those is not always true, but the second of those is generally always true. The total instruction count is the number of instructions from the source code that are actually executed. This isn't the lines of code that people read. For example a loop may comprise 100 iterations and 3 lines of code. That loop will likely result in 300 instructions. If a loop contains a child loop than the instruction count is something like: (iterations * overhead) * (iterations * overhead) I am not a fan of OOP programming because there tends to be a lot of overhead. I understand this overhead helps to bind things together at writing time and share resources at execution time, but at maintenance time years and hundreds of developers later its often a catastrophic mess. I would rather the binding be an explicit call to a reference that I can read opposed to reasoning about flow control that isn't evident from reading the source code. I am also not a fan of pronouns, which in some languages is the this keyword. If I have to guess what a reference is contextually I am wasting time that could be better spent making a code change.
- fouc 8y agoWhy would you think less code means the code is less readable? Does cramming 5 lines of code into 1 line make it less code? No. Reading code is harder, so the less code there is to read, the better.
- ascar 8y agoAs I said in my comment, a lot of the stuff I see as positive for making code more readable more often than not adds extra lines as comments or as code, because you keep it simple. You are right that cramming 5 lines in one, doesn't really reduce code, but I have worked with enough programmers that thought it's a good thing. Sure if you can reduce code without making it more complex, that's a good thing.