Code Quality - CL2 Flashcards
Writing maintainable CSS
MaintainableCSS is an approach to writing modular, scalable and maintainable CSS for small and large codebases.
Semantics
Semantic classes usually work best.
Reuse
Striving for DRY leads to over-thought and over-engineered code. In doing so we make maintenance harder, not easier. Instead of obsessing over styles, we should focus on reusing tangible modules.
IDs
Use IDs whenever you need to enable particular behaviours for browsers and assistive technology. But avoid using them as hooks for styles.
Conventions
MaintainableCSS has the following convention:
.[-][-] {}
Modules
A module, by definition, is a reusable chunk of HTML and CSS. Before a group of elements can be upgraded into a module, we must first understand what it is and what its different use cases are.
State If an element's style needs changing based on its state, we should add an extra class to apply the differences. When necessary, use ARIA attributes for assistive technology, not for styling. In doing so we employ a consistent and inclusive approach to styling.
Modifiers
Like state, modifiers also override styles. They are useful when modules (or components) have small and well understood differences.
Versioning We may, for example, want to A/B test two different versions of a module to see which works best.
Javascript
We may want to use Javascript to apply the same behaviour to multiple modules or components.
Organisation
Good code is easy-to-find and easy-to-find code is well-organised. And so it follows we want our CSS to be well-organised. There are, generally speaking, two approaches to choose from, both of which we’ll discuss in this chapter.
1. CSS in a single folder
2. CSS in a module folder
Link:
https://maintainablecss.com/
Code review process
Before we get into the details of how they work, it helps to understand why code reviews are so valuable. On the surface, you might think it’s because they help uncover bugs. But when you look deeper, the value goes far beyond that.
First of all, code reviews get team members involved in different parts of the system than they’re used to. Team members may be so heads-down and intimately involved with one part of the system that they overlook a simple solution that is obvious to someone not as entrenched in the project. Sometimes, two team members working on similar modules discover, through a code review, that they can share more code than they previously thought. This helps reduce redundancy and keeps the team educated about what everyone is doing.
Another benefit is that code reviews encourage consistent coding standards and help ensure that everyone is on the same page. Coding standards may not seem that important, but cleaner code makes it easier for someone else to come in and start working with it. Additionally, coding standards can help prevent common logic errors or other simple mistakes.
One of the more obvious benefits is that your team as a whole will create better code. More sets of eyes increases the quality of the code, so your project will have fewer bugs and be easier to maintain over time.
These advantages aside, the single biggest benefit of code reviews is the opportunity for education. Senior team members can impart their wisdom and insight to junior team members. Juniors can offer senior coders unbiased and fresh ideas overlooked by someone more set in their ways.
Link:
http://www.digital-web.com/articles/code_reviews_write_better_code_overnight/
Code review theory and toolset
Code review (sometimes referred to as peer review) is a software quality assurance activity in which one or several humans check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation. At least one of the humans must not be the code’s author. The humans performing the checking, excluding the author, are called “reviewers”.
Although direct discovery of quality problems is often the main goal[3], code reviews are usually performed to reach a combination of goals :
Better code quality – improve internal code quality and maintainability (readability, uniformity, understandability, …)
Finding defects – improve quality regarding external aspects, especially correctness, but also find performance problems, security vulnerabilities, injected malware, …
Learning/Knowledge transfer – help in transferring knowledge about the codebase, solution approaches, expectations regarding quality, etc; both to the reviewers as well as to the author
Increase sense of mutual responsibility – increase a sense of collective code ownership and solidarity
Finding better solutions – generate ideas for new and better solutions and ideas that transcend the specific code at hand.
Complying to QA guidelines – Code reviews are mandatory in some contexts, e.g., air traffic software
Supporting tools
Many teams perform change-based code reviews based on general-purpose development tools: Online software repositories such as Subversion, Mercurial, or Git and ticket systems such as Redmine or Trac allow groups of individuals to collaboratively review code. But there are also special purpose tools for collaborative code review that can facilitate the code review process.
Static code analysis software lessens the task of reviewing large chunks of code on the developer by systematically checking source code for known vulnerabilities and defect types.[19] A 2012 study by VDC Research reports that 17.6% of the embedded software engineers surveyed currently use automated tools to support peer code review and 23.7% expect to use them within 2 years.[20] Tools that work in the IDE are especially useful as they provide direct feedback to developers.
Link:
https://en.wikipedia.org/wiki/Code_review
Software metric conception
A software metric is a standard of measure of a degree to which a software system or process possesses some property. Even if a metric is not a measurement (metrics are functions, while measurements are the numbers obtained by the application of metrics), often the two terms are used as synonyms. Since quantitative measurements are essential in all sciences, there is a continuous effort by computer science practitioners and theoreticians to bring similar approaches to software development. The goal is obtaining objective, reproducible and quantifiable measurements, which may have numerous valuable applications in schedule and budget planning, cost estimation, quality assurance, testing, software debugging, software performance optimization, and optimal personnel task assignments.
Link:
https://en.wikipedia.org/wiki/Software_metric
Source lines of code metric
Source lines of code (SLOC), also known as lines of code (LOC), is a software metric used to measure the size of a computer program by counting the number of lines in the text of the program’s source code. SLOC is typically used to predict the amount of effort that will be required to develop a program, as well as to estimate programming productivity or maintainability once the software is produced.
Link:
https://en.wikipedia.org/wiki/Source_lines_of_code
Code coverage metric
In computer science, test coverage is a measure used to describe the degree to which the source code of a program is executed when a particular test suite runs. A program with high test coverage, measured as a percentage, has had more of its source code executed during testing, which suggests it has a lower chance of containing undetected software bugs compared to a program with low test coverage. Many different metrics can be used to calculate test coverage; some of the most basic are the percentage of program subroutines and the percentage of program statements called during execution of the test suite.
Test coverage was among the first methods invented for systematic software testing. The first published reference was by Miller and Maloney in Communications of the ACM in 1963.
Link:
https://en.wikipedia.org/wiki/Code_coverage
