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.

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

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

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

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