C# – Identify this programming style

ccode formattingcoding-style

Some of the legacy code I've inherited uses the fact that C# supports multiple assignment to write code like:

void DisableControls()
{
    ddlStore.Enabled                =
    ddlProgram.Enabled              =
    ddlCat.Enabled                  =
    btnSaveProxy.Enabled            =
    btnCancelProxy.Enabled          =
    btnViewMassManagerProxy.Enabled =
    grdPromo.Enabled                = false;
}

It's a very pretty style, with all the = lined up neatly, and the value being assigned down at the bottom, but it's also a rather annoying one to work with. (And yes, those are tabs lining things up, not spaces).

I would like to know what, if anything, this style implies about the original coder, since I've only seen it on a few occasions before. Does it indicate a C++ background? .NET 1.1? Just someone's personal preference?

Is there any reason that the chained assignment like this would be more efficient than individually setting each control's .Enabled? Less so? (This part was answered by @gnat's comment: This way makes it easy to insert btnWhatever.Enabled = as new buttons are added and delete as some buttons are deleted)

Edit: Other elements of this person's style, assuming the whole file was written by one person (likely but not certain), include putting function arguments on the next line, and putting commas at the beginning of a line instead of the end of the previous line. Example:

PromoUpdate[] GetPromoUpdates(
                            StateField field)
{
    List<PromoUpdate> updates   = new List<PromoUpdate>();
    foreach (PromoOptInState p in field.States.Where(
                                                    x => x.IsDirty))
    {
        updates.Add(new PromoUpdate() {
            promoCode   = p.Code 
            , optIn     = p.IsOptedIn
        });
    }
    return updates.ToArray();
}

It's very weird.

Best Answer

/*********************************************************************
 * People who do indent that way also tend to write pretty comments. *
 * It looks so very pretty, so very professional. Except it's not.   *
 *********************************************************************/

Suppose a variable needs to be renamed for some reason. That simple change might mean lots of superfluous changes because the original author succumbed to the "pretty code" programming style. You as the maintainer have to look at the entire body of code to see if you have broken the prettiness of the code.

Suppose the pretty commentary is flat out wrong. It doesn't describe why the code exists or what the code does. It's pretty, but wrong. Perhaps the original author rethought the design but didn't change the pretty comment. Perhaps some previous maintenance programmer fixed a bug but didn't fix the pretty comment. Perhaps that happened over and over.


There's a big difference between beautiful code and overly pretty code. Beautiful code doesn't need tons of makeup.

Update

That code aligned on the equal signs certainly does look prettier, and is perhaps easier to read, particularly when the targets on the left hand side have only slightly dissimilar lengths. This alignment also serves as a form of self-documenting code to show that that block of assignment statements are somehow related to one another. For these reasons, Steve McConnell advocated aligning the equals signs in a block of assignment statements in the first edition of Code Complete.

However, he withdrew this recommendation in subsequent editions. Instead he explicitly admonished against this style:

Do not align right sides of assignment statements.

His rationale for completely reversing his recommendation in this regard was that the huge maintenance cost associated with this style does not justify that slight increase in readability and comprehensibility.


Regarding the comma-first style, I've seen it and I don't like it. I put it in the same class as yoda conditions (if (42 == foo) do_something(); and if ("foobar".equals(baz)) do_something_else();). To me, both the comma-first and yoda conditions are too jarring to how I normally read and think.

All of this is of course a programming religious issue. Some people love their block formatted assignment statements, others love that comma-first style, yet others love their yoda conditions. My own rule: When I'm maintaining someone else's code I had better adapt to that author's style. New code? If the project give some leeway on style, I'll write that new code in my own preferred style.

Related Topic