Good definition of "consistency"

Question

I am trying to tell someone that his code is not “consistent” in the sense that it fulfills several goals. I don’t think I can explain this very well, so I am looking for a good link and / or definition.

Answer 1

I think the correct term is cohesion .

In computer programming, cohesion is a measure of how strongly related and related the various responsibilities of a software module are. Cohesion is an ordinal type of measurement and is usually expressed as “high cohesion” or “low cohesion” in the discussion.

Modules with a high degree of adhesion are generally preferred because a high degree of adhesion is associated with several desirable characteristics of the software, including reliability, reliability, reusability and comprehensibility, while low cohesion is associated with undesirable traits, such as being difficult to maintain, difficult reusable and even hard to understand.

Answer 2

I had Steve McConnell's Code Complete next to my computer (like the programmer’s bible) with an open page explaining cohesion, so I thought I would share

Cohesion has arisen because of structured design and is usually discussed in the same context as communication. Cohesion how close all the subroutines to the class or all the code in normal mode support the central goal - how focused the class is. Classes containing highly related functionality described as having strong cohesion, and the heuristic goal is to do as much as possible.

Answer 3

I use the term "separation of concerns" to explain this when refactoring. Often, when the code is fairly new, everything will be combined together, as individual issues are not clear at first.

One easy way to show this to your employee is to ask them to write test cases for the code. This should show that the code is not clear or not consistent.

Another useful phrase to use is that functions / objects “must do one thing and do it well”, this has consequences in everything: from the names of objects / methods to the general architecture of the system.

Answer 4

In addition to the answers given so far, an easy way to think about high cohesion is the lack of duplication of functionality and a clear separation of related functions into separate modules, components or classes. That way, if you need a function similar to another function, and you cut and paste and subsequently modify a copy of the code, you decrease integrity. If you change the original to handle a new case, when the new case is clearly related to existing functionality, you increase cohesion. In other words, if your program needs to do a certain thing, no matter how many times or how many places, for maximum cohesion there should be only one piece of code that does this. At the same time, this class, module or component should have one area of ​​responsibility. Combining unrelated functionality into one class or component also reduces grip.

As stated in the CodeWiki, cohesion is usually discussed through communication, where they can act against each other, especially where strict interfaces are not carefully planned. Many of the googled association articles are related to OO design, but cohesion and communication are not limited to OO.

Answer 5

It is marked by an ordered, logical and aesthetically consistent connection of parts; "consistent argument" - from http://www.websters-online-dictionary.org/definition/coherent