To wit: Do we really need 18 lines for each of the delegate's exposed properties?
/// <summary>
///
/// </summary>
/// <returns></returns>
public string GetSomeValue() {
return delegate.GetSomeValue();
}
/// <summary>
///
/// </summary>
/// <param name="value"></param>
public void SetSomeValue(string value) {
delegate.SetSomeValue(value);
}
Each three-line statement has 8 lines of worthless comment and unnecessary vertical white space around it.
I won't argue one way or the other about the need for parallel hierarchies of exposed classes delegating to hidden classes here. I've even left off the fact that there is gratuitous context being used in the real code (I've cleaned this up for your convenience). Ignoring all the other bits of silliness or grand architectural idealism, let's just talk about this very small bit of code.
Why not use this:
public string SomeValue {
get { return delegate.GetSomeValue(); }
set { delegate.SetSomeValue(value); }
}
I think we gain readability by deleting 15 lines of fluff and reducing the namespace pollution by half. The operations group more naturally, so I don't have to remember to mentally group getters and setters. I know that they're going to (and coming from) the same place. And best yet, that little snippet fits in my paltry IDE window.
Spreading a small bit of code out over a large area seems like rude behavior to me.
Okay, I've ranted. Thanks for the time. I'm back to the code.
I get the impression that you're working on a small screen fairly often. If so, do you think the smaller screen influences the compactness of your code? If so, has the influence been positive?
ReplyDeleteActually the screen is pretty big but when I work in VSS+resharper or Eclipse, I tend to have the explorer, unit test panel, and multiple files open in panes at once (because I'd rather refer than remember). Because I remote pair, we find that having panels auto-hide makes the lag time much worse. We dock everything.
ReplyDeleteWhen I'm in python I will have autonose running in a terminal window and I'll have an editor, and an interpreter (idle, ipython, python, etc) going. Sometimes I have the documentation open too. That cuts down the available space quite a bit.
In weaker moments I have tweetdeck and pidgin going, too.
Most of the time I have two screens, and the other may have a browser or some reference docs. I pair remotely, so I'll have a skype session going for access to voice/video of partner. I also use the online stopwatch for pomodoro reasons (48/12 cycles).
So I use the space to see more things, not to see more of the same thing.
I want to see error messages, test fails, test code, the code under test, all at once. I try to adjust for my partners, but I would rather not hunt through tabs ever.
Even when I'm full-screen in vim, I still keep the code small. I simply hate scrolling vertically, and I deeply despise scrolling horizontally (my touchpad and my mouse neither have a horizontal scroller).
So I'm in a small window on a pair of big screens most of the time, and I still end up coding in a little window.
Now that I have a notebook and have to be more careful in my use of screen space I will let you know if it helps.
Oh, and by the way the bigger issue with this particular code was that the vertical spaces and stupid pointless empty comments broke up the grouping of the code. I had to look further to see that it was two parts of the same thing.
ReplyDeleteI suppose that has little to do with screen size and more to do with me not developing beany habits in Java.
This leads into the question of whether it is better to "wrap" 5 very long function calls into (15) <79 character lines, even if that makes the code difficult to understand, or to just let the long calls scroll off of the right side of the screen where interested parties have to scroll over to see the individual objects being passed.
ReplyDeleteI have done it both ways, and seen it done both ways. Either way has issues, depending upon the IDE in use at the time of course.
Of course, I think that function calls shouldn't be that long. I know that M$ and others have created functions with more than 14 parameters, but that doesn't mean it's okay.
ReplyDeleteBjarne Stroustrup once said that in a well-designed system the number of parameters per function call approaches one.
Of course, you end up having to work in ill-designed systems sometimes. :-( I suppose the goal would be to build an API that isn't insane over the one that is. You'll still have the ugliness in your domain impl, but at least it's swept under a rug.
A lot of the stuff I see is decent APIs, but programmers doing things like making long trainwreck function call chains and like bad practices. Tricks like extracting methods and introducing variables often will help a lot.
Just a reminder that newer releases of C# reduce the property syntax so it's now:
ReplyDeleteint Whatever { set; get; }
These have become one-liners: Compressed vertical space, easily scanned by the lightly trained eye.