3 ms·
Regarding 1)... Yes, in this particular case you could just throw an UnrecoverableError (or whatever) and pass a string with a message of what went wrong to its
by Sandman 14y ago
Regarding 1)... Yes, in this particular case you could just throw an UnrecoverableError (or whatever) and pass a string with a message of what went wrong to its constructor. But that wasn't my point at all. I wasn't trying to make a point about how to structure code or deal with errors/exceptions, I was trying to make a point about naming conventions. My example could just as easily have been something like:
"PtgSL. PatagonianSeaLion. Which of these names describes the class better?"
- loup-vaillant 14y agoThe long name, of course. Now whatever you do, long names should be reserved to infrequently used things. If a long name litters your program, you'd better use a shorter one. Conversely, short names belong to frequently used things. This is because a long name is a cognitive burden. On the other hand, one needs to learn what is behind each label, and don't want to forget it. Fortunately, good long names (such as "PatagonianSeaLion") tend to be about very specific things. So specific that you rarely need them. But there can be bad long names, like "System_Out_Println". Something this pervasive should never have such a long name.