Hey you coders

[prog]

These questions aren't language-specific; consider the questions as pseudocode. Pretend that the underscores are actually studlyCaps if you'd like.

Also, don't worry about return values of the mutators, which is a separate question.



[Poll #875101]

Comments

[prog.livejournal.com]

I was intentionally mixing up language styles by not using studlyCaps. My home turf of Perl allows them, but Perl culture tends to frown on their use. I'm pretty sure it's not just because it makes the code look like Java. (Aw, shucks, I can't Google up an image of the cover of The Perl Journal's "Special Java Issue" cover art from a few years back...)

Anyway, I ask this coz Perl culture has long used dual-purpose accessors, but adherents to "Damian style", led by the Perl Best Practices book I just read, advocate explicit separation of getters and setters, and would agree with the reason you give. So I'm of two minds about it right now.

[metahacker.livejournal.com]

StudlyCaps do have the downside of encouraging FileNamesThatLookLikeThis.txt, which can break on non-case-sensitive machines (Macs and, in times past, VMS). And yes, it makes perl look like Java, and who wants to reach all the way over to that shift key anyway? But nowadays even my text editors understand them -- e.g. Ctrl-Left-Arrow in my IDE will move to the next word *part* in a studlyCapped word, which can be very handy.

For a while I stuck with studLy for public methods variables, and lower_underscore() for private methods and internal variables. This got old really fast. Nowadays I just dislike seeing underscores at all, mostly because of people with LJ handles like _________I___AM___K00L_________ and that sort of crap. (Though I retain the _initial_underscore morphology for reserved variables...)

you can grep "set_foo()" easier than "foo"

[taskboy3000.livejournal.com]

The more verbose names are more accurately greppable. Don't underestimate the value of that. :-)