BACKGROUND IMAGE: stock.adobe.com
Every software development team is different, so it's hard to outline a single set of bad coding practices to avoid. Yet, the work is still often the same, which means patterns can emerge.
It's time to stop being a cowboy coder. Beware these seven bad coding practices that can impair the team and project. Chances are, you or your peers committed these faux pas on more than one occasion.
Seven deadly sins of software development
Poor documentation. Documentation is a critical part of code maintainability and reusability. Sometimes, however, developers get so caught up in code creation that they forget to document it. To make matters worse, poorly written documentation might only be meaningful to the person doing the development. Every project should include comments and associated documentation that is readable and meaningful to everyone; write documentation for others -- not for yourself.
Poor architecture. The design of a software project can be more important than the actual lines of code. But when developers rush to begin coding and have to meet challenging deadlines, it takes emphasis away from design. A clear and well-planned architecture outlines how to separate features and functions, which enables smoother delegation of tasks, more efficient coding with less repetition -- resulting in DRY (don't repeat yourself) code -- and greater potential to reuse code across other projects. Invest in design upfront, as it always results in better code.
Poor coding. Always create software in accordance with an organization's coding practices and standards. Standards help ensure that every developer writes code in similar styles and approaches, which leads to easier integration, better readability and lower error rates. Regular code reviews help refine and enforce those standards. When teams don't enforce coding standards or periodic code review, the result is poor quality and inefficient, unreliable code that is harder to maintain and reuse.
Poor problem solving. Developers will encounter challenges during the project's development. For example, a feature might not behave as expected, or a bug could defy remediation. Developers sometimes make choices that only implement temporary fixes. They might use a fallback protocol because the intended protocol imposes excessive latency. Temporary fixes, which replace and forestall addressing and resolving the issue permanently, cause the project to suffer from the accumulation of technical debt.
Poor time management. Software development projects can impose serious challenges in time management. It's easy to underestimate the time required to create a feature or function, and this leads to delays and costly schedule slippage. Time estimates require experience; project managers must confer with developers experienced in the tasks at hand. Regular scheduling and code reviews are crucial to keep a development project on track.
Poor assumptions. It's difficult to stipulate every detail in a software design document. Developers will often make assumptions about certain functional or behavioral details of software. These assumptions usually lead to unnecessary patches and rework, and they often disrupt an already-tight project schedule. Developers should ask clarifying questions and address areas of uncertainty to guarantee the best results from the outset of the project. Schedule regular meetings with the project manager to make sure everyone is on the same page.
Poor testing. Software continues to grow more complex, with ever-greater reliance on open source code, APIs and other resources that might originate from outside the organization. This complexity vastly increases the importance of testing for performance, usability and security. A troubled software release can devastate the business. While testing often relies on automated tools and specialized staff, developers should take an active role in the process. They should test each iteration to ensure that it meets the necessary requirements, a task which might involve contributing to test scripts and even hands-on attempts to break the code to assess its resilience.
Dig Deeper on Code refactoring and management
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.