Comments on: Is That How You Talk To People?

By: Filip Duyck

Filip Duyck — Fri, 30 Jul 2010 10:00:50 +0000

Why not have 2 properties (IsPanelWindowVisible and IsBusy) which you can set to true or false?

By: TDG

TDG — Thu, 29 Jul 2010 09:13:40 +0000

I tend to agree with Matt, having 2 seperate methods is confusing for the developer (especially when the amount of methods is large enough to have to scroll through the suggestions).
When i see HideWindow(), the first thing i wonder is: “is there also a method for hiding the window?” And if there is, what will its name be? UnHideWindow? ShowWindow?
And who guarantees that HideWindow() and ShowWindow() are each others opposite? It’s possible that the author of the code used confusing names for different functionality.

With ShowWindow(bool isVisible) you don’t have these question, you instantly see the method, its possible states and you’re (well, almost) sure true does the opposite of false.
And imho that’s why the boolean-version is easier to read than 2 methods… actually that’s why i’ve written it like that.

By: Davy Brion

Davy Brion — Tue, 27 Jul 2010 07:17:48 +0000

@Matt

interesting point… however, in types that you own i think it’s important to keep the number of members on a class to a respectable number. With that, i mean that it should only have members that make sense for that class, and that should (IMHO) not be a list that is so large that you needs methods to be close to each other alphabetically in order to be easily discovered.

Findability/discoverability begins with a simple, clean and intuitive API. Not with IntelliSense.

@Lars-Erik Roald

Not a big fan of that convention either, but Dispose(bool disposing) is at least not a public member. Not saying that it’s completely ok to give non-public members ‘bad’ names, but there is a good argument to be found to be more lenient about those names.

By: Lars-Erik Roald

Lars-Erik Roald — Tue, 27 Jul 2010 06:56:29 +0000

This example should be quite obvious for everybody – we shouldn’t use the first solution.
Another, more interesting case is: Dispose() and Dispose(bool disposing) . Should we get rid of that syntax? Every time I see this syntax, I need to scratch my head. Does it really need to be like this ?

By: Matt

Matt — Tue, 27 Jul 2010 03:31:10 +0000

Hi Dave

Whilst I like what you’re suggesting (code readability is becoming top of my list), what about intellisense – most devs calling the code will use intellisense to determine what they can do and being ordered alphabetically will mean the ShowPanelWindow and HidePanelWindow methods will be completely separated (causing the dev to have to hunt through before finding out what there is – of course something like resharper will help)..

What I’m getting at is, beyond outright readability is the issue of the tools we use – should we consider findability [or other tool-related issue] too?

Of another way around this is to muddle the order so the noun comes first (i.e. PanelWindowShow and PanelWindowHide) but that isn’t how we talk to people either..

Thoughts?

By: Tiendq

Tiendq — Tue, 27 Jul 2010 01:49:56 +0000

I always prefer the longer version, it saves my time in the long run.

By: Olivier

Olivier — Mon, 26 Jul 2010 19:45:01 +0000

I agree intellectually with you, though I must confess I rather often write this:

private bool dirty = false;

private void SetDirty() { SetDirty(true); }
private void SetDirty(bool isDirty)
{
dirty = isDirty;
}

In my mind, this means that SetDirty actually sets a dirty state given that with no parameter the obvious intention is to ‘set’ the dirty state whereas you must explicitly provide the false value to ‘unset’ it…

As a side note, I hate (could not really explain why) using the ‘this’ keyword when not absolutely necessary. This is why I usually use a different name for the parameter and the member…

By: Victor Kornov

Victor Kornov — Mon, 26 Jul 2010 18:19:12 +0000

It depends on the context and how those 2 methods are used but… If e.g. visibility comes as data the first version is better. I.e. ShowPanelWindow(someobj.IsVisible) is better than if(someobj.IsVisible) ShowPanelWindow() else HidePanelWindow();
There have been cases when I’ve refactored such code “backwards” to your refactoring

By: Michael Kjörling

Michael Kjörling — Mon, 26 Jul 2010 15:42:48 +0000

I agree with the point of this post. Another thing; if the function in question is actually lengthy and/or complex, and/or can’t easily be refactored itself for some reason, you can always make the current code private and simply create wrapper methods with more descriptive names. After all, not all methods are one-liners like the example, and while refactoring to increase readability is a good thing in most instances, sometimes there isn’t time – and then, a little is clearly better than nothing.

By: Hemant

Hemant — Mon, 26 Jul 2010 15:09:58 +0000

Agree. I always tell my team to avoid natural obfuscation. The way they name the code elements and write the logic, it is almost impossible to reverse engineer the real code. Forget REing the IL

By: Davy Brion

Davy Brion — Mon, 26 Jul 2010 15:05:34 +0000

@Hemant

oh don’t get me started on the naming conventions/practices of Microsoft code

but that doesn’t mean you shouldn’t use better naming in your own code

By: Hemant

Hemant — Mon, 26 Jul 2010 15:03:58 +0000

Well… I was not aware of the SL functions since I haven’t coded in SL yet. If that is the case why blame the poor developer… even Microsoft folks don’t know how to talk to people

By: Davy Brion

Davy Brion — Mon, 26 Jul 2010 14:47:50 +0000

@Hemant

btw, in Silverlight, Visibility.Collapsed means => completely hide it… there is no handle to expand again

By: Davy Brion

Davy Brion — Mon, 26 Jul 2010 14:46:00 +0000

@Hemant

would you still go for ToggleVisibility if it would only be called through code? in this particular case, it was only called from code

By: Hemant

Hemant — Mon, 26 Jul 2010 14:43:33 +0000

I would still go with first version but call the methods as “ToggleVisibility”. Then create “IsVisible” or “Visible” property and write IsVisible = !IsVisible. And the with Busy Indicator or Busy State I would go for your implementation. Visibility is typically toggled via some UI element but busy state is generally managed through code. By making visibility as Boolean you can always call it via code. Also another fact is Expand/ Collapse is not same as Show/Hide. When you collapse a control, you typically leave a handle to expand it again. Not the same with visibility.

By: Davy Brion

Davy Brion — Mon, 26 Jul 2010 12:48:38 +0000

@Roy

possibly… i think the fact that it’s fewer code is also something that many developers would use as an argument in favor of the first version

and there’s also the fact that some developers still really don’t know how to talk to people

By: Roy

Roy — Mon, 26 Jul 2010 12:45:47 +0000

I think these practices come from the time that refactoring tools were non-existent. If you rename “BusyIndicator”, your code would require 2 changes instead of just the one.

Thankfully it is not 1759 anymore and we can stop doing these things