iOS Vs Android

- 41studio
- September 9, 2014
- Uncategorized

iOS Vs Android

Which Platform Should I Choose For The Initial Release?

Nowadays, Internet is one of the important elements of the business. And according to internetlivestat.com, about 40% of the world population have an i…

Your checklist for quality code

November 10, 2016

Businesses want high quality codebases and developers want to write high quality code – but what does that really mean? How can you tell if your code is high quality?

Search for a single definition of software quality and you’ll see that it is open to considerable, and sometimes heated, debate. Aside from matters of taste, this is because code quality can’t be defined by a single attribute, but rather through a combination of traits. So how do you identify them?

Over the years, as we’ve talked with customers about what they’re trying to achieve with a code quality solution, the same eight traits keep coming up:

☐ Clear

Can the code be read, understood, and maintained over time, by someone who isn’t the code’s original author. Martin Fowler, an authority on code quality, stated this well: “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”1

☐ Simple

Elegant code that does exactly what is needed and nothing more, sometimes described as “the simplest thing that could possibly work”.

☐ Well-tested

Code is written to achieve a purpose, and testing – either with unit tests or integration tests or both – is the best way to determine if it achieves that purpose and works with the rest of a codebase. Of course, just having lots of tests doesn’t mean code is “well-tested”. The tests themselves must be concise, readable, and comprehensive.

☐ Bug-free

A raincoat that doesn’t keep out water isn’t high quality. For the same reason, the presence of bugs preventing desired behavior is a common marker of low-quality code.

☐ Refactored

Refactored code is code that is not just written once and committed, but iterated on to match best practices and the team’s conventions.

☐ Documented

As with clarity, documentation – inside the code or external – is highly regarded because it supports long-term maintainability.

☐ Extensible

In a business environment, codebases are constantly evolving to meet new requirements. Code that is extensible is prized for its ability to enable developers to rapidly add new features without having to spend a lot of time on maintenance.

☐ Performant

For businesses delivering a service where speed is paramount – say, e-commerce platforms – code is unlikely to be considered high quality unless it’s performant.

Any combination of these can make for great quality code depending on what’s important to your business. The difficulty is deciding what that is as a team.

Perhaps initial time to market is your core business priority – if so, you may not be as concerned about test coverage, and that’s okay.

The important thing is to make sure that everyone contributing to your codebase is on the same page, and the goals for your business and your code are aligned. If not, you risk moving in different directions and not achieving either.

Next time we’ll take a look at how to choose the right complexity metric for your team.

[…]

The Ruby Rails Aggregator