Know what the code block must perform.
Maintain naming conventions which are uniform throughout.
Indicate a brief description of what a variable is for (reference to commenting).
Correct errors as they occur.
Keep your code simple.
Design code with scalability and reuse in mind.

In the context of software engineering, software quality refers to two related but distinct notions:

Software functional quality reflects how well it complies with or conforms to a given design, based on functional requirements or specifications.[1] That attribute can also be described as the fitness for purpose of a piece of software or how it compares to competitors in the marketplace as a worthwhile product.[2] It is the degree to which the correct software was produced. Software structural quality refers to how it meets non-functional requirements that support the delivery of the functional requirements, such as robustness or maintainability. It has a lot more to do with the degree to which the software works as needed. Many aspects of structural quality can be evaluated only statically through the analysis of the software inner structure, its source code (see Software metrics),[3] at the unit level, system level (sometimes referred to as end-to-end testing[4]), which is in effect how its architecture adheres to sound principles of software architecture outlined in a paper on the topic by Object Management Group (OMG).

However some structural qualities, such as usability, can be assessed only dynamically (users or others acting in their behalf interact with the software or, at least, some prototype or partial implementation; even the interaction with a mock version made in cardboard represents a dynamic test because such version can be considered a prototype). Other aspects, such as reliability, might involve not only the software but also the underlying hardware, therefore, it can be assessed both statically and dynamically (stress test).[citation needed]

Functional quality is typically assessed dynamically but it is also possible to use static tests (such as software reviews).[citation needed]

Historically, the structure, classification and terminology of attributes and metrics applicable to software quality management have been derived or extracted from the ISO 9126 and the subsequent ISO/IEC 25000 standard.[6] Based on these models (see Models), the Consortium for IT Software Quality (CISQ) has defined five major desirable structural characteristics needed for a piece of software to provide business value:[7] Reliability, Efficiency, Security, Maintainability and (adequate) Size.[8][9][10]

Software quality measurement quantifies to what extent a software program or system rates along each of these five dimensions. An aggregated measure of software quality can be computed through a qualitative or a quantitative scoring scheme or a mix of both and then a weighting system reflecting the priorities. This view of software quality being positioned on a linear continuum is supplemented by the analysis of "critical programming errors" that under specific circumstances can lead to catastrophic outages or performance degradations that make a given system unsuitable for use regardless of rating based on aggregated measurements. Such programming errors found at the system level represent up to 90 percent of production issues, whilst at the unit-level, even if far more numerous, programming errors account for less than 10 percent of production issues (see also Ninety-ninety rule). As a consequence, code quality without the context of the whole system, as W. Edwards Deming described it, has limited value.[citation needed]

To view, explore, analyze, and communicate software quality measurements, concepts and techniques of information visualization provide visual, interactive means useful, in particular, if several software quality measures have to be related to each other or to components of a software or system. For example, software maps represent a specialized approach that "can express and combine information about software development, software quality, and system dynamics".

A software development methodology is a framework that is used to structure, plan, and control the life cycle of a software product. Common methodologies include waterfall, prototyping, iterative and incremental development, spiral development, agile software development, rapid application development, and extreme programming.

The waterfall model is a sequential development approach; in particular, it assumes that the requirements can be completely defined at the start of a project. However, McConnell quotes three studies which indicate that, on average, requirements change by around 25% during a project.[9] The other methodologies mentioned above all attempt to reduce the impact of such requirement changes, often by some form of step-wise, incremental, or iterative approach. Different methodologies may be appropriate for different development environments.

Program code should not contain "hard-coded" (literal) values referring to environmental parameters, such as absolute file paths, file names, user names, host names, IP addresses, URLs, UDP/TCP ports. Otherwise the application will not run on a host that has a different design than anticipated. A careful programmer can parametrize such variables and configure them for the hosting environment outside of the application proper (for example in property files, on an application server, or even in a database). Compare the mantra of a "single point of definition" (SPOD).

As an extension, resources such as XML files should also contain variables rather than literal values, otherwise the application will not be portable to another environment without editing the XML files. For example, with J2EE applications running in an application server, such environmental parameters can be defined in the scope of the JVM and the application should get the values from there.

Re-use is a very important design goal in software development. Re-use cuts development costs and also reduces time for development if the components or modules which are reused are already tested. Very often, software projects start with a existing baseline which contains the project in its prior version and depending on the project, many of existing software modules and components are reused which reduces development and testing time therefore increasing the probability of delivering a software project on schedule.