Ten Steps to Programming Mastery. Lomont, C. Technical Report 2003.
abstract   bibtex   
[Excerpt] Here are ten ways you can improve your coding. The overriding principle to improving your skill at coding, as well as almost endeavor, is open your mind and then fill it with better knowledge. Improvement necessarily implies change, yet it is human nature to fear and resist change. But overcoming that fear and embracing change as a way of life will enable you to reach new levels of achievement. [...] [::Big Rule 1: Break your own habits] When you began coding, you were much less experienced than you are now, and you probably picked up bad habits out of ignorance. Now is the time to change these habits, but they are difficult to find, and embarrassing to recognize. The best ways to locate weaknesses in your programming ability are to read others code and think about it, discuss your code with others to get new viewpoints, and to read, read, read! [...] [::Big Rule 2: Apply defensive programming] Your code will constantly be under assault, from idiot users, poor hardware, buggy drivers, incompetent maintenance programmers, cosmic rays, and general bit-rot. It will be pushed to the boundaries of its design, passed unholy parameters, and forced to run on systems unforseen at the time of its creation. So design your functions and interfaces appropriately, expecting Murphy's Law to be elevated to a Law of Thermodynamics. [...] [::Big Rule 3: Don't be so macho] [...] Just because you know all the inline tricks, routinely use the intricacies of operator precedence, prefer function pointers to functions, and have mastered language subtleties, does not mean you should use them in a masochistic mental ritual. Sure it looks neat, impresses colleagues, and is a fun intellectual exercise, but the end result is code that is so hard to understand that people will either break it during maintenance, avoid it from confusion, or just scrap it and waste time and money rewriting it. Program as if your code was written to be read by programmers several levels beneath your level, and you will be praised for the beauty of your code. You will also find your code is easier for you to read and understand next year, and that it is easier to debug and make flawless. [...] [::Big Rule 4: Use your tools wisely] Use all the tools that are available to you. Spend time to learn them. Smart people spent a lot of effort designing and building your tools, and they are designed to speed up your development, so use them. At least be sure to find out what is there, and how to use them - if they turn out to be crap, you can ignore them. But if they have nifty feature Z, and your current programming would really, really be better with a feature Z, and you do not realize it is already there, then you will either reinvent feature Z or, more likely, you will do without, plugging away in tears in your dark cubicle. So occasionally click on the option you do not understand, and learn a new feature. [...] [::Big Rule 5: Learn your language] C++ has a lot of areas, some of which truly are esoteric, but there are many useful features programmers often do not understand. [...] The moral is: the STL has many features and functions that will make you more productive and your code more nearly correct. [...] [::Big Rule 6: Learn common errors and avoid them] There are a few errors so common, that they account for over 90\,% of all errors at the programming level, so it is wise to learn them. When they are about to rear an ugly pointer, a little extra diligence will prevent the problem. [...] [::Big Rule 7: Pull each other up] Everyone in the group, from neophyte programmer, to tenderfoot, to journeyman, to adept, to unkempt old-timer, has knowledge that others do not. Learn from each other. Ask questions, have people look over pieces of your code, ask for suggestions, and stimulate and push each other to improve in your mastery of the language, tools, and environment. You are not smart enough to invent all the useful techniques a good programmer should know. No one is that smart, but the sum total of all the knowledge of all the smart people that came before you is available to learn in a fraction of the time it took to invent, so learn some. Find good books on others bookshelves. Read newsgroups. But doing it as a group helps all, since the fewer bugs any one member of the group introduces into the code base, the less time the entire group has to spend fixing things. [] The bottom line is that is is a lot quicker to learn something from someone who knows it already than to read it yourself, and it is exponentially quicker to learn from others mistakes than to reinvent all those errors yourself. [::Big Rule 8: Do not reinvent the wheel] It is fun and instructive to write that quicksort, that red-black tree, and that MD5 hashing function for yourself, but you should not be reimplementing algorithms and code that is built into your tools, or is easily obtainable. In the same manner you do not build a hacksaw each time you need to remove handcuffs (well,... sorta like that), you should not recreate others work. One reason is that well tested, banged upon pieces of code are much less likely to hide subtle errors than your 20 minute afternoon attempt at a binary search. Another reason is that often libraries have been built by people that have invested significant mental energy and time to optimize them, and you should build upon that effort. [...] [::Big Rule 9: Code clearly] The main purpose of code is not for telling machines what to do, which sounds ridiculous on the surface. Source code is a language for communicating with humans what you want a machine to do. Your source code is a book, a novel, a piece of art, that others must read and understand, work on, extend, and utilize. Although you do not have the poetic license that a poet does, slinging symbols all over a blank page, you are creating literature, since people will read your code and understand it. So program accordingly. Unfortunately, since the very literal computer must also understand what you write, you must cross your t's and dot your i's (and close your braces, and free your resources, and a million other '' grammatical'' rules). The bottom line is that you must find a delicate balance between making your code correct, and making it very readable and understandable. [] So we agree that it is important to make your code easy to read. Clearly show the intent of routines, objects, files, libraries, parameters, data flow, assumptions, preconditions, et cetera ad infinitum. Polishing off your masterpiece with consistent spacing and concise precise commenting make your code a gem. [::Big Rule 10: Continue learning] The most important, lasting area of knowledge you can improve is your knowledge of algorithms. Algorithms are the building blocks, and dictate how you will design code, how you will solve problems, and how effectively you can change an approach to a problem. [...] The second most important learning area is how to design medium and large scale systems [26]. A 100 line program is easy to do - place the lines in almost any order it runs. 1000 lines is also not too hard - you can still understand the whole program, and probably stomp out all the bugs. 10,000 lines takes a little longer to write, takes time to debug, and is still probably not flawless. But if you want to handle 100,000 line programs, or perhaps 1,000,000 line programs, a very very large part of the success will of the system be in the design that was done before any code was written. It is not unlike building a jigsaw puzzle. You can probably complete a 30 piece puzzle in a minute, but it is doubtful you can do a 3000 piece puzzle in 100 minutes. The complexity of such tasks is rarely linear in input size. [...]
@techreport{lomontTenStepsProgramming2003,
  title = {Ten Steps to Programming Mastery},
  author = {Lomont, Chris},
  year = {2003},
  abstract = {[Excerpt] Here are ten ways you can improve your coding. The overriding principle to improving your skill at coding, as well as almost endeavor, is open your mind and then fill it with better knowledge. Improvement necessarily implies change, yet it is human nature to fear and resist change. But overcoming that fear and embracing change as a way of life will enable you to reach new levels of achievement. [...]

[::Big Rule 1: Break your own habits] When you began coding, you were much less experienced than you are now, and you probably picked up bad habits out of ignorance. Now is the time to change these habits, but they are difficult to find, and embarrassing to recognize. The best ways to locate weaknesses in your programming ability are to read others code and think about it, discuss your code with others to get new viewpoints, and to read, read, read! [...]

[::Big Rule 2: Apply defensive programming] Your code will constantly be under assault, from idiot users, poor hardware, buggy drivers, incompetent maintenance programmers, cosmic rays, and general bit-rot. It will be pushed to the boundaries of its design, passed unholy parameters, and forced to run on systems unforseen at the time of its creation. So design your functions and interfaces appropriately, expecting Murphy's Law to be elevated to a Law of Thermodynamics. [...]

[::Big Rule 3: Don't be so macho] [...] Just because you know all the inline tricks, routinely use the intricacies of operator precedence, prefer function pointers to functions, and have mastered language subtleties, does not mean you should use them in a masochistic mental ritual. Sure it looks neat, impresses colleagues, and is a fun intellectual exercise, but the end result is code that is so hard to understand that people will either break it during maintenance, avoid it from confusion, or just scrap it and waste time and money rewriting it. Program as if your code was written to be read by programmers several levels beneath your level, and you will be praised for the beauty of your code. You will also find your code is easier for you to read and understand next year, and that it is easier to debug and make flawless. [...]

[::Big Rule 4: Use your tools wisely] Use all the tools that are available to you. Spend time to learn them. Smart people spent a lot of effort designing and building your tools, and they are designed to speed up your development, so use them. At least be sure to find out what is there, and how to use them - if they turn out to be crap, you can ignore them. But if they have nifty feature Z, and your current programming would really, really be better with a feature Z, and you do not realize it is already there, then you will either reinvent feature Z or, more likely, you will do without, plugging away in tears in your dark cubicle. So occasionally click on the option you do not understand, and learn a new feature. [...]

[::Big Rule 5: Learn your language] C++ has a lot of areas, some of which truly are esoteric, but there are many useful features programmers often do not understand. [...] The moral is: the STL has many features and functions that will make you more productive and your code more nearly correct. [...]

[::Big Rule 6: Learn common errors and avoid them] There are a few errors so common, that they account for over 90\,\% of all errors at the programming level, so it is wise to learn them. When they are about to rear an ugly pointer, a little extra diligence will prevent the problem. [...]

[::Big Rule 7: Pull each other up] Everyone in the group, from neophyte programmer, to tenderfoot, to journeyman, to adept, to unkempt old-timer, has knowledge that others do not. Learn from each other. Ask questions, have people look over pieces of your code, ask for suggestions, and stimulate and push each other to improve in your mastery of the language, tools, and environment. You are not smart enough to invent all the useful techniques a good programmer should know. No one is that smart, but the sum total of all the knowledge of all the smart people that came before you is available to learn in a fraction of the time it took to invent, so learn some. Find good books on others bookshelves. Read newsgroups. But doing it as a group helps all, since the fewer bugs any one member of the group introduces into the code base, the less time the entire group has to spend fixing things.

[] The bottom line is that is is a lot quicker to learn something from someone who knows it already than to read it yourself, and it is exponentially quicker to learn from others mistakes than to reinvent all those errors yourself.

[::Big Rule 8: Do not reinvent the wheel] It is fun and instructive to write that quicksort, that red-black tree, and that MD5 hashing function for yourself, but you should not be reimplementing algorithms and code that is built into your tools, or is easily obtainable. In the same manner you do not build a hacksaw each time you need to remove handcuffs (well,... sorta like that), you should not recreate others work. One reason is that well tested, banged upon pieces of code are much less likely to hide subtle errors than your 20 minute afternoon attempt at a binary search. Another reason is that often libraries have been built by people that have invested significant mental energy and time to optimize them, and you should build upon that effort. [...]

[::Big Rule 9: Code clearly] The main purpose of code is not for telling machines what to do, which sounds ridiculous on the surface. Source code is a language for communicating with humans what you want a machine to do. Your source code is a book, a novel, a piece of art, that others must read and understand, work on, extend, and utilize. Although you do not have the poetic license that a poet does, slinging symbols all over a blank page, you are creating literature, since people will read your code and understand it. So program accordingly. Unfortunately, since the very literal computer must also understand what you write, you must cross your t's and dot your i's (and close your braces, and free your resources, and a million other '' grammatical'' rules). The bottom line is that you must find a delicate balance between making your code correct, and making it very readable and understandable.

[] So we agree that it is important to make your code easy to read. Clearly show the intent of routines, objects, files, libraries, parameters, data flow, assumptions, preconditions, et cetera ad infinitum. Polishing off your masterpiece with consistent spacing and concise precise commenting make your code a gem.

[::Big Rule 10: Continue learning] The most important, lasting area of knowledge you can improve is your knowledge of algorithms. Algorithms are the building blocks, and dictate how you will design code, how you will solve problems, and how effectively you can change an approach to a problem. [...] The second most important learning area is how to design medium and large scale systems [26]. A 100 line program is easy to do - place the lines in almost any order it runs. 1000 lines is also not too hard - you can still understand the whole program, and probably stomp out all the bugs. 10,000 lines takes a little longer to write, takes time to debug, and is still probably not flawless. But if you want to handle 100,000 line programs, or perhaps 1,000,000 line programs, a very very large part of the success will of the system be in the design that was done before any code was written. It is not unlike building a jigsaw puzzle. You can probably complete a 30 piece puzzle in a minute, but it is doubtful you can do a 3000 piece puzzle in 100 minutes. The complexity of such tasks is rarely linear in input size. [...]},
  keywords = {*imported-from-citeulike-INRMM,~INRMM-MiD:c-14215506,check-list,computational-science,non-linearity,programming,robust-modelling,semantics,software-uncertainty},
  lccn = {INRMM-MiD:c-14215506}
}
Downloads: 0
About
Documentation
Keywords
Search
Users
Terms and Conditions of Use
Privacy Policy
Sitemap
© BibBase.org 2021