Whether you write an article or a computer program. It's the same.
When you write, you feel confident about your work. This confidence is actually bad. It prevents you from reading your work again. Even if you did, you will read it with confidence lens and eventually change nothing.
You should slide down the confidence equalizer while reading your own work and remove those confidence lens. Its healthy.
You will end up peeling a lot of unnecessary words and sentences and paragraphs. Then you will free the simple, beautiful and the core idea of your work dancing through the words. This too will keep your work short and sharp and solid for people to actually read.
That works too for programmers.
When you write, you feel confident about your work. This confidence is actually bad. It prevents you from reading your work again. Even if you did, you will read it with confidence lens and eventually change nothing.
You should slide down the confidence equalizer while reading your own work and remove those confidence lens. Its healthy.
You will end up peeling a lot of unnecessary words and sentences and paragraphs. Then you will free the simple, beautiful and the core idea of your work dancing through the words. This too will keep your work short and sharp and solid for people to actually read.
That works too for programmers.
This comment has been removed by the author.
ReplyDeleteI go for clarity when writing code, and sometimes clarity requires writing less code, but sometimes it requires writing more code.
ReplyDeleteLike for example I write long variable names so that the code is quite clear, take a look at this:
if (c.getNoc() > 5) {
c.split();
}
You have to trace the code to find out what this means, but if I write it like this:
if (cable.getNumberOfConnections() > 5) {
cable.split();
}
It's obvious what it does.
Another example is complex if statements, sometimes inside the code you read something like this:
cable.setSize(((cable.getLength()>cable.getMaxCableSize())?
cable.getMaxCableSize():cable.getLength())/cable.getCapacity());
Writing it as:
double cableSize;
if (cable.getLength() > cable.getMaxCableSize()) {
cableSize = cable.getMaxCableSize() / cable.getCapacity();
} else {
cableSize = cable.getLength() / cable.getCapacity();
}
cable.setSize(cableSize);
Much longer but much easier to read and process.
Note that those sample codes have no logic in them, I just made up variable and method names on the fly.
@Yaseen
ReplyDeleteI agree with you,
Programming is Art, you need sometimes to write more to be clear..
But still sometimes when you read your code more than once you can trim it and remove unnecessary statements.
Got to find some examples for that.. Or write a new post dedicated to that purpose.
Nice post. I do agree that you should not write more than what is necessary to get the point across meaningfully.
ReplyDeleteI fully agree. It is important to use the KISS Principle whether we are writing, coding or performing any activity. Keeping it simple is actually more difficult than initially anticipated. As Leonardo Da Vinci mentioned "Simplicity is the ultimate sophistication".
ReplyDeleteNo doubt about rereading my code and making it shorter, I do it all the time :)
ReplyDeleteAt once, I had to write three big methods, after I were done with them, I looked at the big picture, I rewrote the three methods into one smaller method that did all their jobs combined and handled even more cases.
@Cody
ReplyDeleteYes writing too much is in our nature to show that we know. Avoiding that is difficult as Elie explains..
@Elie
Thanks Elie, you taught me that Principle and it is really hard to apply it in our activities. It requires practice. I try to achieve it with my blog posts..
@Titi
Yes I do that all the time too, I write a function that achieve a single task in two classes, after reading it I delete everything and combine it in one simple class that actually does the code more efficiently .
Keeping in mind to keep things clear.. That is really difficult you know especially with Code..