Representation of a question mark in variable names [closed]
https://softwareengineering.stackexchange.com/questions/252448
-
04-10-2020 - |
Question
I once in my childhood read a SF story in which it was assumed that the capital letter 'P'
would be a good representation for a question mark, if you cannot use that character directly, eg. in variable names. However the story is quite old and things may have changed :)
Is this a good practice?
BTW: The story was called Press Enter by John Varley
Edit
Additional questions that are answered below.
Is this only writer's phantasy or is it based on an actual language's habit?
If yes, which language would that be?
Solution
Many communities have naming conventions for making predicates stick out. In Java, they are prefixed with has
or is
(isEven
), in Ruby and Scheme, they are suffixed with ?
(even?
) and in some other languages, they are suffixed with p
or _p
(evenp
, even_p
). At first glance, it has a bit of a "Bad Hungarian" smell, but actually I find it makes code more fluent.
Haskell doesn't use any markers, they trust the types (anything which returns a Bool
is a predicate, e.g. even :: Integral a ⇒ a → Bool
).
If your community uses and understands that convention, you should follow it.
Naming predicates ending with p
is indeed somewhat common, but that has nothing to do with the looks of the letter p
, it is simply an abbreviation of "predicate". Here's an example of some functions from the CommonLISP ANSI spec:
adjustable-array-p
alpha-char-p
alphanumericp
array-has-fill-pointer-p
array-in-bounds-p
arrayp
bit-vector-p
both-case-p
boundp
char-greaterp
char-lessp
char-not-greaterp
char-not-lessp
characterp
compiled-function-p
complexp
consp
constantp
digit-char-p
endp
equalp
evenp
fboundp
floatp
functionp
graphic-char-p
hash-table-p
input-stream-p
integerp
interactive-stream-p
keywordp
listp
logbitp
lower-case-p
minusp
next-method-p
numberp
oddp
open-stream-p
output-stream-p
packagep
pathname-match-p
pathnamep
plusp
random-state-p
rationalp
readtablep
realp
simple-bit-vector-p
simple-string-p
simple-vector-p
slot-boundp
slot-exists-p
special-operator-p
standard-char-p
streamp
string-greaterp
string-lessp
string-not-greaterp
string-not-lessp
stringp
subsetp
subtypep
symbolp
tailp
typep
upper-case-p
vectorp
wild-pathname-p
y-or-n-p
yes-or-no-p
zerop
OTHER TIPS
That would not really be universally understood, so I wouldn't recommend it.
Additionally, some languages actually use the ?
to check if a variable is defined, so if you named a variable CompletedP
and you want to check if that is defined, that would be CompletedP?
. This would just give me a headache.
Generally, where I would think this could be appropriate, I would just change the name of the variable into an obvious question. So the following variables could be renamed:
TaskACompleted?
->IsTaskACompleted
ButtonChanged?
->HasButtonChanged
etc.
In languages with a malleable syntax such as Lisp or Scala, the question mark is in fact allowed and is frequently used to mark Boolean functions.
Where it isn't, I've never seen a P substituted to mimic a ?
. isValidP()
doesn't really look very much like a ?
to me.
There is in fact a certain tradition of using a suffix of P
to mark predicates (i.e. Boolean functions), but there the P
stands in for 'predicate', not for the shape of the ?
. (Strangely, this is also prevalent in Lisp, so I assume it was from a time or dialect that didn't actually allow ?
in identifiers.)
In Groovy language, the question mark has some functionality.
Imagine that you have a company and it may or may not have a location filled in the system. Same goes for its entire address fields. Now, if I want to get the street name, in similar languages like Java, I'd have to deal with null values. Not in Groovy!
String streetName = company.getLocation()?.getStreet()?.getStreetName();
With that said, I think it's a bad idea to include ?
in the variables/methods name. P cannot replace it also, it doesn't look like a readable code to me, I'd choose hasButtonChanged() instead of buttonChangedP() every single time, day and night.
The man who taught me to program many many years ago once told me this -
"Any damn fool can write code a computer can understand. To write code that a human can understand takes skill".
In general, anything which makes your code less human-readable is a really, really bad idea. Especially selecting arbitrary characters to replace characters which could just as easily be escaped.