numberOf* vs *Count
In the PDF specification, the two terms are used interchangeably. However, when programming, it is helpful to establish a consistent naming convention so that programmers do not need to keep looking up the attribute names.
There are currently two ways of naming values that represent the count/number of records or values:
|
outputStream.write_unsigned_int(self.numberOfFixedDatumIDs) |
|
outputStream.write_unsigned_int(self.numberOfVariableDatumIDs) |
vs
|
self.falseTargetCount = falseTargetCount |
Pros and cons
Pros of numberOf* naming
Pros of *Count naming
- convenient visual alignment (
fixedDatumIDs and fixedDatumIDCount will left-align for easier visual identification when browsing code)
- shorter attribute names
This is admittedly a minor issue and might not affect many users, though it's clear where my biases lie. Currently it's a minor speedbump for my work on the repo, and I can wait for a resolution on (a) whether consistent naming would be beneficial, (b) which naming convention to go with.
numberOf* vs *Count
In the PDF specification, the two terms are used interchangeably. However, when programming, it is helpful to establish a consistent naming convention so that programmers do not need to keep looking up the attribute names.
There are currently two ways of naming values that represent the count/number of records or values:
open-dis-python/opendis/dis7.py
Lines 48 to 49 in 9312cb2
vs
open-dis-python/opendis/dis7.py
Line 537 in 9312cb2
Pros and cons
Pros of numberOf* naming
Pros of *Count naming
fixedDatumIDsandfixedDatumIDCountwill left-align for easier visual identification when browsing code)This is admittedly a minor issue and might not affect many users, though it's clear where my biases lie. Currently it's a minor speedbump for my work on the repo, and I can wait for a resolution on (a) whether consistent naming would be beneficial, (b) which naming convention to go with.