Things you should keep in mind. Lets face it, every developer wants to improve and become better. The big question that most developers ask is how will I do it. Here are a list of things you should keep in mind while . programming Code Presentation As any discussion about code layout grows, the probability of it descending into a fruitless argument approaches one. You know the tabs vs spaces, bracket placement weather on new line or the same line. A good code format is not the one you think looks prettiest. A good format is the one that makes it easier to scan and read the code. Good code presentation reveals your code’s intent. It is not an artistic endeavor. We need good presentation to avoid making code errors. Not so we can create pretty ASCII art. We write code to be executed by a computer, but to be read by humans. If any man wishes to write a clear style, let him first be clear in his thoughts. Pick one layout style and use it consistently or adopt coding standard or style guide. If you’re working in a file that doesn’t follow the layout conventions of the rest of your project, follow the layout conventions in that file. Naming A good name is descriptive, correct, and idiomatic. You can only name something well if you know exactly what it is. Make sure you know what it is before giving cryptic names to variables. Avoid redundancy. It shows you didn’t think through the naming of what you are building. Be it a class or function or variables class ItemList { public int numberOfItems () {…} }// numberOfItems is unnecessarily long, repeating the word Item// it could be renamed to size or even length Employ the capitalization conventions most often used in your language. Like in methods are capitalized C# Console.WriteLine("Hello World") Ensure that your names are accurate and avoid spelling mistakes. Never alter presentation and behavior at the same time. Make them separate version-controlled changes. Adapt your presentation style as you gain experience. As a beginner you don’t always start out with good code presentation, your are more concerned about whether the program works or not. Write Less Code Writing lots of code does not mean that you’ve written lots of software. It may just mean you are written lots of bugs. More code means there is more to read and more to understand — it makes our programs harder to comprehend. The more code you have, the more places there are for bugs to hide and tracking them down may not be that easy. Avoid Unnecessary Code Common class of pointless code is the unnecessary use of conditional statements and tautological logic constructs. Flappy logic is the sign of a flappy mind. // exampleif (expresion) {return true;} else {return false;}// which can be refactored toreturn expresion; Express code clearly and succinctly. Avoid unnecessarily long winded statements. They don’t add any value to your code. Duplication Do not copy code sections. Factor them into a common function. Use parameters to express any differences. If you spot duplication, remove it. Dead Code Dead code is code that is never run, that can never be reached. Tell your code to get a life, or get lost. Other manifestations of dead code include: Functions that are never called Variables that are written but never read Parameters passed to an internal method that are never used Enums, structs, classes, or interfaces that are never used Comments Good code does not need reams of comments to prop it up, or to explain how it works. Make sure that every comment adds value to the code. The code itself says what and how. A comment should explain why — but only if it’s not already clear. Do not remove code by commenting it out. It confuses the reader and gets in the way. Every day, leave your code a little better than it was. Remove redundancy and duplication as you find it. Improve Code by Removing It You can improve a system by adding new code. You can also improve a system by removing code. How dead code spring up during development Features are removed from an application’s user interface, but the backend support code is left in. Wizard-generated UI code inserts hooks that are frequently never used. Remove dead code wherever possible. It gets in the way and slows you down. It is safe to remove code that you might need in the . You can always get it back from version control. future Code cleanup should always be made in separate commits to functional changes. Dead code happens in even the best codebases. Be wary of the Past You thought it was perfect when you wrote it, but cast a critical eye over your old code and you’ll inevitably bring to light all manner of code gotchas. Looking back at your older code will inform you about the improvement (or otherwise) in your coding skills. How to go about an existing codebase Coming into any large existing codebase is hard. You have to rapidly: Discover where to start looking at the code Work out what each section of the code does, and how it achieves it Gauge the quality of the code Work out how to navigate around the system Understand the coding idioms, so your changes will fit in sympathetically Find the likely location of any functionality (and the consequent bugs caused by it) Your best route into code is to be led by someone who already knows the terrain. Don’t be afraid to ask for help! The best way to learn code is to modify it. Then learn from your mistakes. Many programmers, rather than putting in the effort to read and understand existing code, prefer to say “it’s ugly” and rewrite it. Be prepared to encounter bad code. Fill your toolbox with sharp tools to deal with it. Some filthy code was simply written by a less capable programmer. Or by a capable programmer on a bad day. Silence the feeling of revulsion when you encounter “bad” code. Instead, look for ways to practically improve it. You can’t expect any code, even your own, to be perfect. Follow the Boy Scout Rule. Whenever you touch some code leave it better than you found it. Make code changes slowly, and carefully. Make one change at a time. Dealing with Errors Do not ignore possible errors in your code. Don’t put off handling errors until “later” (you won’t get around to it). Use exceptions well, with discipline. Understand your language’s idioms and requirements for effective exception use. Programmers must be made aware of programmatic errors. Users must be made aware of usage errors. It’s not good enough to log the error (somewhere), and hope that a diligent operator will notice an error and do something about it one day. Be prepared for the Unexpected At every step, consider all of the unusual things that might occur, no matter how unlikely you think they’ll be. Always consider errors that you can recover from, and write appropriate recovery code. Ensure that your error handling is idiomatic, and uses the appropriate language mechanisms. Consider all potential code paths as you write your code. Do not plan to handle “unusual” cases later: you’ll forget and your code will be buggy. Bug Hunting Programmers write code. Programmers aren’t perfect. The programmer’s code isn’t perfect. It therefore doesn’t work perfectly the first time. So we have bugs. We should always employ sound engineering techniques that minimize the likelihood of unpleasant surprises. Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. Reduce bugs to the simplest set of steps possible. reproduction Ensure that you are focusing on a single problem. Assertions and logging ( ) are potent debugging tools. Use them often. even the humble console.log and nodejs assert Binary chop problem spaces to get results faster. As you develop your software, invest time to write a suite of unit tests. Untested code is a breeding ground for bugs. Tests are your bleach. Learn how to use your debugger well. Then use it at the right times. Fix bugs as soon as you can. Don’t let them pile up until you’re stuck in a code cesspit. Debugging isn’t easy. But it’s our own fault. We wrote the bugs. Always test your code Unit tests specifically exercise the smallest “units” of functionality in isolation, to ensure that they each function correctly. This isolation specifically means that a unit test will not involve any external access: no database, network, or file system operations will be run. Quality is free, but only to those who are willing to pay heavily for it. To improve our software development we need rapid feedback, to learn of problems as soon as they appear. Good testing strategies provide short feedback loops. Write tests as you write the code under test. Do not postpone test writing, or your tests will not be as effective. All tests should run on your build server as part of a continuous integration tool chain. Test whatever is important in your application. Global variables and singleton objects are anathema to reliable testing. You can’t easily test a unit with hidden dependencies. Factoring your code to make it “testable” leads to better code design. Program testing can be used to show the presence of bugs, but never to show their absence. How to deal with complexity Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better. Complexity is generally accidental, rarely something someone adds willfully. Defer design decisions until you have to take them. Don’t make architectural decisions when you don’t know the requirements yet. Don’t guess. Practice Makes Perfect A programmer needs good taste and a sense of aesthetics to write exceptional code. Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction. Good software development is not cowboy coding, throwing down the first code you can think of. It is a deliberate, considered, accurate endeavor. Good programmers work with humility. They admit that they don’t know it all. Good code and good coders are born from a desire to write the right thing in the right way. Be a team player Programming teams have a set of rules. These rules define what we do and how we do it. But they also describe a coding culture. Don’t rely on vague unwritten team “rules.” Make the implicit rules explicit, and take control of your coding culture. Apply bug fixes to the root cause, not where symptoms manifest. Sticking plaster symptom-fixes do not lead to simple code. Avoid implicit assumptions in your code. Only write as much code as is needed. Anything extra is complexity that will become a burden. Stop and think. Don’t write stupid code. Admit to your mistakes and bad coding decisions. Learn from them. Have the courage to use your brain. Feel empowered to critique code and make decisions about how to improve it. Learn what makes software easy to change, and strive to craft software with these attributes. To modify code you need courage and skill. Not recklessness. Often it is best to make a series of frequent, small, verifiable adjustments, rather than one large sweeping code change. Avoid copy-and-paste coding. Factor your logic into shared functions and common libraries, rather than suffer duplicated code (and duplicated bugs). Write small, modular sections of code. Keep it clean and neat. Code should be “shared” because it is useful to multiple clients, not because the developers want to create a nifty shared library. Don’t dismiss other people’s code. It may be better to use existing libraries rather than write your own version. Creating software releases requires discipline and planning. It is more than hitting “build” in a developer’s IDE. Always build your software in a fresh checkout, from scratch. Never reuse old parts of a software build. Make your build as simple as a single step that automates all parts of the process. Use a scripting language to do this. Deploy your builds on a CI server to ensure their health. Make formal releases from the same system. Be in a state of continual learning. Always look to learn something new. Our learning is often too narrowly focused. Consider a wider sphere of reference. Draw inspiration from many fields. Takes notes as you learn. Even if you throw them away. If you can’t explain it simply, you don’t understand it well enough. Teach a topic to learn that topic well. I hear and I forget. I see and I remember. I do and I understand. Using what you just learned cements it in your memory. Try examples, answer questions, create pet projects. Be wary of stagnation. Seeking to become a better programmer, by definition, is not the most comfortable lifestyle. Expect to invest time and effort to grow your skill set. This is a worthwhile investment; it will repay itself. Do not make yourself “indispensable” by writing unreadable or unnecessary “clever” code. Honour software licenses. Don’t become a one-trick pony. Position yourself to face new challenges, learn, and grow as a developer. Love All Languages Learn languages that follow different idioms and paradigms. Consider also learning some “dead” languages that are no longer commonly used, to understand the history of your craft. A good programmer knows many languages, and multiple idioms, broadening their palette of solutions. It improves the code they write. Working with your programming language is a relationship you have to work at each day. To write the best code in a language, you should commit to its styles and idioms rather than force your own upon it. Good programmers are good communicators. They talk, write, code, listen, and read well. Don’t expect to become a language master overnight, and don’t get frustrated whilst you work at it. Concentrate effort on the most important things first. What is most urgent, or will produce the most value? If you do something often, make the computer do it for you. Automate it with a script. Split large tasks up into a series of smaller, well-understood tasks. You will be able to judge progress through these more accurately. Make sure you define “done.” If you can’t tell when it’s done, then you shouldn’t start it. Use tests written in code to define when your code is complete and working. Don’t do more work than necessary. Work until you’re “done.” Then stop. When facing a problem, make sure you’ve considered more than one approach to solve it. Only then should you start working on it. Purposefully place yourself beside excellent programmers. More comments do not necessarily make your code better. Communicative code does not need extra commentary to prop it up. Learn about development methodologies, trends, manifestos, and fads. If you found this post helpful, please share it so that others can find it. You can follow me on GitHub and LinkedIn . If you have any ideas and improvements feel free to share them with me. 💪 Happy coding!

Chain

Too Long; Didn't Read

Making security fun one episode at a time

139 Traits That Make A Better Programmer

Too Long; Didn't Read

Coin Mentioned

Sadick

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

139 Traits That Make A Better Programmer

Too Long; Didn't Read

Coin Mentioned

Sadick

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES