Good code...
As in all writing, whether in programming languages or human language, easy to read is a matter of context and audience. When you are first learning to code or if your whole development team is new to a programming language "easy to read" means lots of explanatory comments and white space. Later on, when you and your teammates are more experienced, those very same comments can seem like clutter and the white space can make the code so spaced out that it is difficult to skim. print "@{[%$hSomeHash]}\n" is easy for a Perl expert to read without comment, but probably makes your average Perl newbie's head spin (it did mine the first time I saw it). However, as long as you focus on getting things to work and checking in with others (and yourself) about the readability of your code, I suspect you will do fine.
When you get further on in programming and have to design large programs, there are a lot of other issues to consider: common standards for teams and associated issues of compliance; which combinations of paradigms (object oriented, functional or procedural) are best for a particular problem; architecture; testability; maintainability; re-usability; and so on. But even on big programs, the same issues are still there: an architecture that is so convoluted that it takes a new team member six months to learn better be solving a really complicated problem that really, really can't be solved any other way. Generally, the best solutions still are (a) easy for you to read and (b) easy for others to read, even on the large scale.
Best, beth
In reply to Re: How to write good code?
by ELISHEVA
in thread How to write good code?
by ahhlun
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |