Overview
The same thing as in Inconsistent Names applies to the general formatting and code style used in the project. Browsing through the code should have a similar feeling to reading a good article or a book - consistent and elegant. In the project, the code layout should not be changed preferentially or randomly but should be uniform so as not to disturb the expected form of code in the following lines
Reading a novel where on each page, the reader is surprised by the new font ranging from Times New Roman through Comic Sans up to Consolas is distracting and could break out of the flow state.
Another example of an Inconsistent Style smell could be Sequence Inconsistency, for example, in the order of parameters within classes or methods. Once defined, the order should be kept in the group of all abstractions on that particular subject. If the order is not preserved, it leads, once again, to the unpleasant feeling of dissatisfaction after (if ever!) the mind realizes that it was again surprised wrong. Depending on the specific case, it would still be only half the trouble if the flipped parameters were of different types (such as string and int). If the type were the same (e.g., int), this could lead unnoticeably to a significant hidden bug.
Causation
Team members working on the same project disagreed on one particular coding style, linter, or code formatter. In the worst case, different people could use different formatters or different formatting rules and overwrite the whole files with their style of choice over each other, littering the git history with new commits.
Problems
With advanced IDE type-hinting nowadays, change is smaller, but when a bug gets introduced by a sequence inconsistency, it might not be enjoyable to find out its root cause.
Depending on the state of code, the comprehensibility issues that the inconsistent style can cause range from irrelevant up to illegible.
Familiarity is an essential factor in code orientation and navigation.
Example
1my_first_function(
2 arg1=1,
3 arg2=2,
4 arg3=3
5)
6my_second_function(arg1=1,
7 arg2=2,
8 arg3=3)
9my_third_function(
10 arg1=1, arg2=2, arg3=3)1class Character:
2 DAMAGE_BONUS: float
3
4 def rangeAttack(self, enemy: Character, damage: int, extra_damage: int):
5 total_damage = damage + extra_damage*self.DAMAGE_BONUS
6 ...
7
8 def meleeAttack(self, enemy: Character, extra_damage: int, damage: int):
9 total_damage = damage + extra_damage*self.DAMAGE_BONUS
10 ...
11
12witcher.rangeAttack(skeleton, 300, 200)
13witcher.meleeAttack(skeleton, 300, 200) # potentially overlooked errorRefactoring
- Introduce Linter Rules
- Reorder Parameters
Sources
- ORIGIN