Re^2: Code Maintainability

[mpeever]

in reply to Re: Code Maintainability
in thread Code Maintainability

Consider this instead:

my $circle = Circle->new(
    radius     => 4.5,
    origin     => [2.3, 2.2],
    visibility => 1,
);

I agree that named parameters are a huge win. That's a bit of Lisp and PL/SQSL I miss frequently in other languages.

And frankly, without named parameters, it seems to me the convenience constructor debate really becomes a choice between the lesser of two evils. On the one hand we can be verbose, on the other we can be cryptic. I personally prefer cryptic to verbose: I expect a maintainer to look up parameters as he or she needs.

But I return to my thesis: maintainability is a red herring. If we choose which idioms to use based on aesthetic value, we eliminate the problem. We both agree that a constructor taking a series of numbers is ugly. But I would argue that :

my $capital = Capital -> new ("Canada", "Ottawa");

Is obvious and very maintainable, even though it's conceptually the same pattern.

My conclusion is that a sense of code aesthetics allows us to choose the best (or least evil) option on a case-by-case basis.

[autarch]

Actually, I think it's more than just cryptic vs verbose. One of those examples has a serious logical flaw, and the other doesn't.

my $circle = Circle->new();
# What is $circle now?!
$circle->set_radius(4.5);
# or now?
$circle->set_origin(2.3, 2.2);
$circle->set_visibility(1);

See those comment I added? When you first create a circle object without any parameters, what is it, logically speaking? It has no radius and no origin, so it's more like a theoretical circle, but not representative of any real-world circle.

After we set a radius, it starts to make sense, though maybe in our particular app circles always need an origin too.

This dovetails with one of my newer mantras, which is that mutable state is evil. In the "pass everything to the constructor" version, we might be able to avoid (or at least limit) our mutators. If we're lucky, there's no need to change the radius of a circle, we can just make new ones with different radii. Avoiding mutable state greatly simplifies code. It makes APIs smaller, and makes reasoning about an application much simpler.

Java, with it's regular pattern of "construct, set, and call", makes mutable state a given, and that's a terrible thing to do.