Between, CREATE lab internship and GSoC work, and Startup Engineering course, I have been doing quite some amount of coding these days. I am learning some good lessons during all this coding, and thought it might be a good idea to jot them down for myself, and share with anyone who is interested.
The most important thing which I realized is that the amount of time spent understanding and reading the code is much much more than the amount of time spent writing that code. So, it makes sense to write the code in such a way that the amount of time spent on reading/understanding the code can be minimized. Also, 90% of the optimization happens in only 10% of the code, and sometimes it is better to write more readable code than writing optimized code.
The most important thing which I realized is that the amount of time spent understanding and reading the code is much much more than the amount of time spent writing that code. So, it makes sense to write the code in such a way that the amount of time spent on reading/understanding the code can be minimized. Also, 90% of the optimization happens in only 10% of the code, and sometimes it is better to write more readable code than writing optimized code.
- Explaining what the code in a particular file does, along with the licensing info at the beginning of the file is actually a pretty good idea. And so is describing what does a function do at the beginning of the function.
- It's better to use elaborate names for variables and functions, which are self explanatory, rather than using concise variable names. It's even better to use function names which are don't include the technical lingo and are rather understandable by a user who don't have a great idea about the library being used by you. chooseVisual() is a much better function name than, createEGLConfiguration().
- Instead of aiming for writing the most optimized code from the beginning it is better to write the most readable code, and then try to optimize it. Also, using temporary variables is not really that a bad idea if they can make your code easier to understand.
- It makes a lot of sense if the same convention for naming functions and variables is used throughout the code base (assuming there are multiple engineers working on the code base). Also, if you use the same indentation style, and commenting style, your code might start looking good too. As of ow that seems to be the toughest thing to achieve, a good looking code. But, I am working towards it, hopefully I should get the hang of it.
2 comments:
good looking codes!!!..finally someone said it...I think everyone can write so under no time constraint rule, but it doesnt work out all the time and in the end all they see is the output and suffer through delirium while writing codes to achieve so
How to Make Money from Betting on Sports Betting - Work
(don't worry Get air jordan 15 retro if งานออนไลน์ you get it wrong, though) The process involves placing bets on different events, but it can also discount air jordan 23 shoes online be 고양에프씨 done by Air Jordan 21 retro using the
Post a Comment