I always assumed it was 'short' that was the issue -- so file systems that only allowed 8.3 for the file names. One underscore, and you've just lost 12% of your working space (as the extension is fixed)
| [reply] |
| [reply] |
One thing that's annoyed me inordinately in the past is Getopt::Long, whose principal function is called GetOptions. I've written use GetOpts::Long; Getoptions(); or similar, so many times that I had to write a script to generate boilerplate just to save my sanity... | [reply]
[d/l]
[select] |
| [reply] |
Mostly. Now I only have to remember the three switches for the boilerplate script. This means I have at least 0.01% more space in my head for The Voices.
| [reply] |
<AOL>
M3 T00!!!11!1!!!
</AOL>
| [reply] |
I hate StudlyCaps too, so I always name modules with single words. Nouns, typically.
In object oriented terms, I have found that if I need an adjective to describe a classname, then there's probably some inheritance of more fundamental features.
For example, say I want an interactive widget. Thinking about it, I realize that the adjective clues me in on the possibility of other kinds of widgets. I may or may not be better served with a separate namespace like Widget::Inert and Widget::Interactive under the more general Widget namespace and class. But I very rarely would use a name like InteractiveWidget which just looks BuTtTuGly to me.
One thing to keep in mind: if you're using a lot of other people's modules from CPAN, then you're going to have to accept the names they already have, so you might as well become disabused of your notions of avoiding all StudlyCaps entirely.
--
[ e d @ h a l l e y . c c ]
| [reply] |
I think it is a good standard and feel that it helps visually reinforce code structure.
use module_name::sub_class; <-yuk
| [reply]
[d/l] |
Historically, that would be anything on a FAT drive: DOS, OS/2. I'm sure that back in '95, '96, some may have included Win95 in the list as well, being a bit scared of the new extentions to the FAT filesystem therein. (I'm just waiting for my last OS/2 machine to die on me ... going on 7 years old :-})
Today, with DOS a mere memory that is fading, at least for most people, and OS/2 being officially withdrawn from the marketplace (for the fourth or fifth time, I think, if one were to believe the tech-news), or even the very small numbers of OS/2 users that still use FAT (HPFS being far, far superior in every way), I'm not sure what reason is left for short names.
That said, I still see value in differentiating our 'bare' words: often we use UPPERCASE for constants (or constant subs) and perlish APIs (e.g., DESTROY, BEGIN, END), or lowercase for scope-limited variables. CamelCase for packages, and under_scores for functions works for me.
| [reply] |
| [reply] |
