The most important things of Software Development
1. Comment your code
Commenting your code will make you realize what that part of your code actually does and document it for you as well as others.
If you ever come back to that code, or anyone else for that matter, a short and descriptive comment will tell you everything you need to know.
If you check a function, it should have a comment describing it.
If you write the implementation code, it should document what you’re doing.
A bit of duplication (descriptive variable names plus comments) are ok, but don’t overdo it.
Variable names …, that brings us to the next point.
2. Use descriptive Variable and Function Names
Think about them.
Nowadays code is about readability and maintainability (more on that later). So even if your names tend to grow longer than other ppls, that’s ok.
Find a compromise of readability and descriptiveness and usability (auto-complete in editors is helpful).
If you really want to optimize or obfuscate, do so later, with a tool.
Some coding styles and guidelines specify for example that class members/properties begin with an m_, or that integers begin with an i.
This can be a valid and useful convention as well.
Modern IDEs may make the datatype prefixing obsolete, because you can easily see it.
But conventions/prefixes to distinguish scope or security (user input vs stripped user input) can still be very useful. (A reference to Golang here, where Capitalized properties and methods are public, and non-capitalized ones are not – by the standard! – Awesome.)
3. Use version control
Really, you should use a good version control for everything. And by everything I mean absolutely everything.
Writing yourself a TODO text file? Version it.
Writing some documentation? Version it.
Doing some image editing? Version it.
I use it regularly and it came in super handy for my Bachelor Thesis and papers, just like for pretty much anything else.
And where it came from, versioning code, is obviously where it is even stronger.
My suggestion is learn and use Git. It’s local, fast and does really good compression. You will have to learn it though, the concepts, but those are what makes it so great.
Working on something? Have to fix something first? Stash, branch or commit your code.
Whatever version control you use, make sure it is fast. Why? See next point.
4. Commit early, Commit often
So you’re using version control, right? Commit your changes! As often as you can (without breaking things for others).
If you use a decentralized version control, even better! You can commit your breaking changes and not push them, or just tag and branch them, and nobody else will be hindered while you have your progress saved, your ideas, your changes. If anything every happens you can go back to it, see it, use it. Committing early will also make it easier to follow your progress, if anyone does.
When I code for 2 hours without a commit I already get an itchy feeling, a need to commit. That’s where you have to get to.
5. Test your code
Properly Testing has great advantages. First of all, you think about what you code. How can you test it? What is that part of code supposed to do? You automatically document what is to be done and separate logic into smaller, testable parts. Properly testing also includes testing the edge- end error-cases. What could go wrong? Is it handled, and how?
With a good architecture and (Unit-)Testing framework/technology/architecture you will have fast running tests. Made a change and committed your code (remember?)? Run all your tests! 2 Seconds, in which you can continue to code, and all your functionality has been tested to not have changed. You broke nothing, go on coding!
Be aware of what testing is in contrast to coding. You code in a constructive mindset. For testing, you have to switch to a destructive mindset. Don’t build the tests for your code so they do not fail. Build your tests against the specification and plan. Test edge- and error cases. What is the worst thing that could happen? What is the worst thing a user or machine could enter, send or call? Test for that. Be as destructive as possible. Being as destructive as possible makes you as constructive as possible because you construct such a solid, well documented and tested piece of code. You can proof how good it is by pointing at your passing tests. (A reference to test coverage here, which are mechanisms of calculating your test-quality.)****
6. Use an issue tracker and add TODOs
For planning out and documenting bugs and features, you need to track them. Use an issue tracker for public documentation which is also useable by non-coders and non-commiters. It also allows you to collaborate, assign and point to.
Add TODOs and FIXMEs in your code, wherever something is missing, incomplete or a known issue at a known place. When used correctly (meaning, you actually come back to them) they are very handy.
Although it does not really fit into this section, I will add it here as you can at least document the issue/mark it with TODOs: Never comment out code. That is a rule with exceptions of course. But be aware of this very common problem/danger in software development of commented out code. Later on you, or better yet other people, will not know what to do with it. If you can comment out code, you can probably remove it. If you comment it out to replace it with new logic you are currently coding add a TODO REMOVE to it. Maybe even mark it with a date and name (this can be handy in many other cases as well). This way you (and others) will more often come back to it because it is marked with a TODO, and others will actually know they can remove it (if your new code was commited/pushed and works anyway, which is when commented out code is not noticed any more and orphans).
7. Use Tools!
Defining a coding style because you are not alone? (You should even if you are.) Use a tool to enforce it.
Whatever you do, think about tools and automation. With some scripts you can really improve your workflow and work efficiency.
Do you have a wiki in your company and/or for your product? Wikis are a good and easy way to collaborate in text. Document your ideas and information. Where can I find what? What and where are the dependencies?
Do you version your files?
Do you do automated backups?
Use an IDE? This really is a) often a preference thing and subjective, b) depends (especially which to use) on your language and technology you are using.
Use Continuous Integration?
For bigger projects with a large codebase, a team, a long lifespan or a lot of distributedly incoming changes a build server with automatic test-checking can be really useful.
Use static code analysers to check for errors and problems and get some recommendations.
Use tools to generate doc from your in-line documentation.
When compiling, use your compilers flags to print out warnings and suggestions. They will often help you and/or make sure you use good practices.
8. Be Open
Whatever you do, learn and/or decide on: Be open for new things, techniques, architectures, languages, tools, people, ideas, standards and technologies.
We are in an ever changing and improving world in our global community called Internet. You have tons of choices for pretty much anything you look for, be it product, specification or architecture, or information in general.
You think Java/C#/C++/Python/PHP is the best programming language? You got the whole thing wrong. It’s about your specific focus, your specific use-case. There are no bests.
Even best practices and design patterns are limited to specific focuses or use-cases.
Whenever you start a new project, ask yourself, is using the previous technology the best choice? Whenever you have the chance, learn something new. Be it using it yourself, evaluating it, or reading about it, be it article or (blogosphere-) discussion. You will not have the time to learn and read about everything, but whenever you can, do!
9. Code first, optimize later
Writing efficient code is awesome fun. Still, you should first focus on getting your features out, in the most simple way you can think of. Then, when it works but is not good (/fast) enough, use a profiler (again, a toll) and optimize where your bottle-neck is. Often you would optimize at the wrong ends and lose a lot of time optimizing while coding where it will really benefit the user and end result at all, because the expensive computations are done elsewhere.
10. Find Colleagues / Find a community
Coding alone is fun and good training. But you tend to lose focus and fun. Find some colleagues or a project you want to contribute to and/or a community to discuss with. With other people on the same project your focus, fun and continued interest will be save/amplified.
Although this is more of a thing for FOSS projects, it also applies to work. With a (nice) team on a project you can discuss with you will enjoy it a lot more. Be it a good or bad project.
Now, I probably missed something. What else big is there? What do you think of this list? Would you prioritize in this order?
PS: I can really suggest taking a look at Golang, to every developer and programmer. It has many concepts built-in which makes life so much easier and work so much more efficient for a developer. With godoc, gomake, goinstall, gofmt you have handy tools at hand. And the language itself is very interesting and very well planned out as well, I love it.
Also, thank you to everyone contributing to open, free and freely available products and information. You, we make the world a greater place – with free flow information leading to a lot of knowledge, options and choices.