Steps
- Gather complete requirements.
Take the time to write down what the end product needs to achieve. Clarity of thought at this stage will save a lot of time down the line. - Write an implementation plan (or model).
- For something small and self-contained, this might just be a basic flowchart or an equation.
- For larger projects, it helps to break it into modules and consider what job each module must do, how data gets passed between modules, and within each module how it will function.
- Although it is fun to dive straight into code, it is equally tedious to spend hours debugging. By taking the time to design the structure on paper, you will drastically reduce your debugging time (and you may also spot more efficient ways of doing things even before you write the first line of code).
- Add Comments to your code.
Whenever you feel your code needs some explanation, drop some comments in. Each function should be preceded by 1-2 lines describing the arguments and what it returns. (Comments should tell you why more often than what. Remember to update the comments when you update your code!) - Use naming conventions for variables.
It will help you keep track of what type the variable is and also what it's purpose is. Although this means more typing than x = a + b * c, it will make your code easier to debug and maintain. One popular convention is Hungarian notation where the variable name is prefixed with its type. e.g. for integer variables, intRowCounter; strings: strUserName. It doesn't matter what your naming convention is, but be sure that it is consistent and that your variable names are descriptive. (See Warnings below) - Organize your code.
Use visual structure to indicate code struture. i.e. indent a code block that sits within a conditional (if,else,...) or a loop (for,while,...) Also try putting spaces between a variable name and an operator such as addition, subtraction, multiplication, division, and even the equal sign (myVariable = 2 + 2). As well as making the code more visually elegant, it makes it much easier to see the program flow at a glance. (See tips on indentation below) - Test.
Start by testing it with inputs that you would typically expect. Then try inputs that are possible but less common. This will flush out any hidden bugs. There is an art to testing and you will gradually build up your skills with practice.
Write your tests to always include the following:- Extremes: zero and max for positive values, empty string, null for every parameter.
- Meaningless values, Jibberish. Even if you don't think someone with half a brain might input that, test your software against it.
- Wrong values. Zero in a parameter that will be used in a division, negative when positive is expected or a square root will be calculated. Something that is not a number when the input type is a string, and it will be parsed for numeric value.
- Practice. Practice. Practice.
- Be prepared for change.
In a realistic working environment, requirements change. However, the clearer you are at the start about the requirements and the clearer your implementation plan, the less likely those changes will be down to misunderstanding or "Ah, I hadn't thought of that" scenarios.- You can take an active role in improving clarity of thinking by presenting your requirements document or your implementation plans before coding to ensure that what you are planning to create is actually what's been asked for.
- Structure the project as a series of milestones with a demo for each block. Approach the programming one milestone at a time - the less you need to think about at any moment, the more likely you will think clearly.
- Start simple and work towards complexity.
When programming something complex, it helps to get the simpler building blocks in place and working properly first.
For example, let's say you want to create an evolving shape on screen that follows the mouse and where the degree of shape change depends on mouse speed.- Start by displaying a square and get it to follow the mouse, i.e. solve movement tracking on its own.
- Then make the size of the square relate to mouse speed, i.e. solve speed-to-evolution tracking on its own.
- Finally create the actual shapes you want to work with and put the three components together.
- This approach naturally lends itself to modular code writing, where each component is in its own self-contained block. This is very useful for code reuse (e.g. you want to just use the mouse tracking in a new project), and makes for easier debugging and maintenance.
- Start small, aim for things that you most likely will be able to achieve, and work your way up.
- Tutorial sites are an excellent resource as well.
- Reading the work of others (source code) is an excellent means of improving ones skills. Better still, work your way through their code by eye, working out the flow and what happens to the variables. Then try to write your own code to do the same thing (or maybe even improve on it). You'll quickly learn why things need to be written a certain way and you'll pick up some useful tips on how to write efficiently.
- Talk to other programmers. People can often be a good resource for information, particularly when starting out. Find out whether there's a group of programmers who meet up locally.
- Have fellow programmers read your code. You would be surprised what they know that you may have never thought of before!
Don't know any professional programmers? Find an online forum that's dedicated to your chosen programming language / operating system.- If you go down this route, read and observe the forum etiquette. There are lots of good hearted experts willing to help out... if asked the right way.
- Remember to be polite because you're asking for a favour, don't get frustrated if you don't understand everything at once, and also don't expect them to want to review 10,000 lines of code. Instead ask simple, single-focus questions and post just the relevant 5-10 lines of code that it relates to. That way you're most likely to get a positive response.
- But before you start posting, do a search - your question has almost certainly been encountered and solved already.
- Keep your past work, it is a good point of reference.
- Keep your code visually elegant, not because it's pretty but because it makes it easier to read... essential when you come to make a change in 6 months' time. This means using TAB indentation to differentiate lines of code that are encapsulated (if, for, while, etc...). Read more about code indenting.
- Find an editor that uses colour-coded syntax-highlighting. It really helps to separate comments from keywords from numbers from strings, etc. (Better still, use an IDE. See below.)
- Double check spelling/syntax. A slight mistake can cause a lot of stress.
- Use a debugger tool. Instead of placing statements in your code to output variable values or "Got here", a debugger tool will let you step through your code line by line so that you can see where it's going wrong.
- Change one thing at a time when debugging and then test your corrections before moving on the next item.
- Separating (packaging) your reusable code from your application-specific code will over time lead to a large, debugged, reusable (without copy/paste) library full of handy utilities. This will aid in writing more powerful and stable applications in less time as your library grows.[1]
- After each bigger segment of work, take a break doing something else, then review what you have written with a fresh mind; rethink and rewrite it, making it more effective and elegant by using less code. Repeat until perfect.
- A program such as Visual Basic .Net can cost a lot of money to purchase and upgrade, and it's syntax style is very different than most other languages. If you MUST use visual basic, go out and download Visual Studio Express Beta 2 2005 from www.microsoft.com or you may buy the student or learning editions.
Remember programming languages like Java, PHP, Python and Ruby, available at no cost. Also, if you want to (must) use a Microsoft but not Visual Basic, there are free open source IDEs for C#, whose syntax resembles Java, etc. - Use an IDE (Integrated Development Environment). A good IDE will have a colour-coded editor built it, with code hints and code completion that make editing faster and less prone to spelling mistakes. It will usually have a debugger built in too.
- Use version control management. Tools like CVS or SVN make it even easier to track code changes and bugs. Once you get used to it you won't look back.
- Customers and bosses aren't concerned with how your program works nearly so much as they are with how well it works. Think bottom line. Clients are intelligent, but busy. They won't care what kind of data structures you're using, but they will care if it speeds up performance by 10%.
- Save your work frequently as you go along or you risk losing hours and hours of work to a computer crash or lock-up. If you ignore this warning now, it's a lesson you will learn the hard way!
- In step 4, Hungarian notation (indicating a variable's type as a prefix) should be used with caution. It can lead to inconsistency when edited, or particularly if ported to another language / operating system. It is of most use in 'loosely typed' languages, that don't require you to pre-declare the type of a variable.
- Copying and pasting others' code is a bad habit, especially if you weren't supposed to see the source. But all things considered, taking small portions from an open source program could be a learning experience. Just don't completely copy a program and attempt to take credit for it.
- Always test your code
- Don't copy code from another program unless you have permission or the license permits it, like Open Source licenses.
- Make regular backups of your application code onto another hard drive or portable device, that way you will have a copy if your computer dies or becomes unavailable - remember to keep the copy in a secure place.
- Ideas
- IDE (Integrated Development Environment)
- Computer
- Reference books or web tutorials
Courtesy: www.wikihow.com
No comments:
Post a Comment