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

[metahacker.livejournal.com]

...except I prefer Java's standards, which are getFoo() and setFoo().

I have an intrinsic dislike -- learned from LISP, where this caused a bug that took about a week to track down -- of having method names that look like variable names.

[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. :-)

[wrog]

method names that look like variable names.

while this sort of thing does bother me, I'm not sure it's the right argument. get_foo() could be doing all sorts of random things behind the scenes and you'll never know.

I think the real argument against having the same method used as accessor and mutator is the same argument against having the same-named method doing entirely semantically different things depending on the type of an argument or the presence/absence of an optional argument. If munge(x) does something different from munge(), really have no business giving it the same name.

I also hate studly caps. If you're going to have multiple words in your variable names, then, dammit, have actual multiple words complete with spaces to make them legible -- that is what you need the underscores for. As for them being ugly, ugliness is in the eye of the beholder.

[dougo.livejournal.com]

If you're going to have multiple words in your variable names, then, dammit, have actual multiple words complete with spaces to make them legible -- that is what you need the underscores for.

Real programmers use hyphens. :)

[temvald.livejournal.com]

I have enough of a dislike of using underscores in method names that I couldn't bear to vote for get_foo(), and so chose Other instead. But you could probably count that as a vote for get/set if you wish. :)

[prog.livejournal.com]

And so I shall. I went ahead and added another line to the preamble asking to pretend that the underscores are studlycaps, if you'd like. Jeez, you people.

[lorelei-sakai.livejournal.com]

Mine, too, can be considered a vote for Java style.

[brentdax.livejournal.com]

My votes (for object.foo([new value])) are only for Perl. Really, I prefer whatever the language usually uses.

Although what I really prefer is object.foo and object.foo = new value, but we'll have to wait for Perl 6 to really do that properly.

[novalis.livejournal.com]

I'll second the really.

[prog.livejournal.com]

lvalues are weird.

[novalis.livejournal.com]

I want the ability to have the interface of an object be a set of fields, and then the ability to change my mind on the implementation.

[misuba.livejournal.com]

Thirded. Of course, I get to do it in Ruby right now :-P

[dougo.livejournal.com]

I've grown accustomed to Common Lisp's (foo object) and (setf (foo object) new-foo-value), which I've also started to use in Scheme dialects that have extensible set! (like Swindle). But since Scheme is a Lisp₁ instead of a Lisp₂, it does sometimes get in the way when you want to have a variable with the same name as an accessor function. I haven't decided yet if this matters enough.

[dougo.livejournal.com]

I should mention that (setf (foo object) new-foo-value) is pretty much equivalent to the object.foo = new_foo_value that brentdax likes.

[cortezopossum.livejournal.com]

I'm somewhat new to object-oriented languages like this (I grew up with super old-skool BASIC and FORTRAN knowledge). I prefer the separate but more readable methods set_foo and get_foo (or setFoo and getFoo .. whatever).

I'd say 'overloading is overrated' but there are times when it's really handy. I'll just say 'overloading is easily abused'.

[radtea.livejournal.com]

The get/set style in any form is to be vastly perferred. As someone else here pointed out, it can be searched on more easily, and that alone is sufficient reason to prefer it to foo() foo(new foo).

I neither know nor care about Java, as Perl and Python are my preferred scripting languages, but in C++ most of the libs I use, and the coding standards I adhere to in most of my professional work, and the code my xml-driven code generator writes (now available in a new and better incarnation), all use some variant of the get/set style.

Software development is hard, and it became very clear in the 90's, if not before, that conciseness is not in general a virtue, even in algorithmic code. Reminding people, especially the poor (usually junior) maintenance coders, what code is doing in multiple ways is a best practice.

For commericial development of application code that will be maintained over many years, there is really no alternative to get/set, preferably in the getX/setX form rather than with underscores, which are ugly and hard to read (but that's an unjustifiable personal preference, unlike the superiority of get/set.)

[chocorisu.livejournal.com]

Explicit set/get to be clear and unambiguous. But make sure they ONLY get/set and don't do potentially length calculations: anything that does more than a tiny bit of arithmetic should be named something else to make it clear that it's actually doing some work.