| ... |
... |
@@ -6,9 +6,7 @@ |
| 6 |
6 |
| Abstraction Level | For example, with functions, the level of abstraction refers to how general or specific the function is, with higher levels of abstraction representing broader, more general functionality and lower levels of abstraction representing more detailed, specific operations. | |
| 7 |
7 |
| [[Acceptance Test|doc:Software Engineering.Agile.Extreme Programming.Acceptance Tests.WebHome]] | See link. | |
| 8 |
8 |
| [[Agile|doc:Software Engineering.Agile.WebHome]] | See link. | |
| 9 |
|
-| Aside | An off-topic comment in the source code, which is usually to be avoided because it distracts from the main purpose of the code, making it harder to understand. | |
| 10 |
10 |
| Assertion | An assertion function, a crucial part of testing. If the input values don't satisfy a certain condition, the test containing the assertion fails. Example: `assertEquals(expectedResult, actualResult)`. | |
| 11 |
|
-| Attribution | Something used to keep track of who wrote or modified a piece of code. Usually handled automatically by a source code control system like Git. | |
| 12 |
12 |
| Awareness | A class A is aware of class B if it contains a reference to class B in its source code. If no such reference exists, class A is unaware of class B. | |
| 13 |
13 |
| Behavior | Counterpart to implementation. It refers to the observable actions performed by a component. For example: A class may have the only observable method `sort(Collection: SomeCollection)`, which says what it does, but no implementation details like what concrete sorting algorithm is used. | |
| 14 |
14 |
| Best Practices | Widely accepted guidelines designed to enhance programming productivity and code quality. Adherence can prevent many potential issues. | |
