2
\$\begingroup\$

I was writing the below section of code which adds some user properties to an Active Directory user, and got wondering - surely we can improve the readability of this :

var firstname = newUser.FirstName;
var lastname = newUser.LastName;
var email = firstname + lastname + "@mydomain.com";
var dotname = $"{firstname}.{lastname}";
var fullname = $"{ firstname} { lastname}";

// Create the new user
var user = myLdapConnection.Children.Add($"CN={firstname} {lastname}", "user");
// Add properties
user.Properties["userprincipalname"].Add(email);
user.Properties["samaccountname"].Add(dotname);
user.Properties["sn"].Add(lastname); 
user.Properties["givenname"].Add(firstname);
user.Properties["displayname"].Add(fullname);
user.Properties["description"].Add(newUser.JobTitle);
user.Properties["mail"].Add(email); 
user.Properties["homedirectory"].Add($@"\\File\Home$\{dotname}");
user.Properties["homedrive"].Add("H:");
user.CommitChanges();

So I added some tabs after my property-name calls like so :

// Add properties
user.Properties["userprincipalname"].Add(email);
user.Properties["samaccountname"]   .Add(dotname);
user.Properties["sn"]               .Add(lastname); 
user.Properties["givenname"]        .Add(firstname);
user.Properties["displayname"]      .Add(fullname);
user.Properties["description"]      .Add(newUser.JobTitle);
user.Properties["mail"]             .Add(email); 
user.Properties["homedirectory"]    .Add($@"\\File\Home$\{dotname}");
user.Properties["homedrive"]        .Add("H:");
user.CommitChanges();

Now I think that makes the code a lot more readable, but I have not seen many people take this approach when formatting. Is there any reason for this? I generally do this in both PowerShell and C#, but are there any languages where this is not acceptable for reasons other than the code wont run?

\$\endgroup\$
  • 1
    \$\begingroup\$ The only downside I can think of is that you'll be creating more work if you need to add a new line there and the key is longer than the previous longest one. \$\endgroup\$ – overactor Jun 7 '16 at 10:31
  • 1
    \$\begingroup\$ Readability is very subjective in these situations. I personally find the first version easier to read as the second version breaks the statement into two parts, which makes it harder for me to read (I'm flicking my eyes back and forth between the two parts to work out what the whole statement does). \$\endgroup\$ – David Arno Jun 7 '16 at 10:55
4
\$\begingroup\$

I think that's fine. The dot operator is an operator like any other, so you can line it up if you think that will improve readability. It's particular useful for "fluent" style method calls:

myList
    .Where(x => ...)
    .Select(x => ...)
    .OrderBy(x => ...)

I don't think however that lining up the dots in your particular code snippet is the best possible solution there. You are violating the DRY principle ("don't repeat yourself"). This text is repeated 9 times in your code: user.Properties[].Add().

You could write it like this:

// Add properties
var userProps = new Dictionary<string, string>
{
    {"userprincipalname",   email},
    {"samaccountname",      dotname},
    {"sn",                  lastname},
    {"givenname",           firstname},
    {"displayname",         fullname},
    {"description",         newUser.JobTitle},
    {"mail",                email},
    {"homedirectory",       $@"\\File\Home$\{dotname}"},
    {"homedrive",           "H:"},
};

foreach (var prop in userProps)
    user.Properties[prop.Key].Add(prop.Value);

I don't believe that lining stuff up takes more time in general. On the contrary, I think it saves time because it makes stuff easier to read. And there are tools for lining stuff up. (I'm not sure if that paticular alignment extension is the one I use myself. I don't have Visual Studio on this computer. But it looks like a good one.)

\$\endgroup\$
6
\$\begingroup\$

Disclaimer: I never wrote code like that, I do not see a reason to do it and I discourage everyone to do it. This however may be seen as nothing else aside of a preference.

But what are you trying to achieve?

Prefectionism?

I do not associate myself with perfectionism, and even if I did as I stated, I doubt I would include this on the things I must do to keep the code 'perfect'. Being perfectionist does not mean that you are egocentric. If you are not a egocentric perfectionist you may relize that the set of rules that you would like to apply doesn't need to be the same set of rules of another perfectionist.

Maintanability?

How is that code more maintanable than the other without spaces/tabs? It is less maintanable because I have to spend more time adjusting the identation when adding a new property

Readability?

If we are aiming readability maybe we have another options, for example:

user.Properties["userprincipalname"].Add(email);
user.Properties["givenname"        ].Add(firstname);

This is a formatting issue, and all formating issues should/must be automatically verified by a static analyzer like resharper, or rubberduck-vba, or wathever. Most of them allow you to configure all settings once and share among all developers so the code is written always with the same formatting.

TLDR

In the end you must confess that what you really want to write is the following:

user.Email = email;
user.FirstName = newUser.FirstName;

And you can. I'll list the steps needed to do it:

  • Create a class with a constructor that recieves the ldap user
  • Foreach property setter write to the respective ldap property Name
  • Foreach property getter get the value from the respective ldap property Name
\$\endgroup\$
  • 1
    \$\begingroup\$ BTW probably you will also want to pass newUser to that class. It seems that you have all the data needed to set the properties on the construtctor. \$\endgroup\$ – Bruno Costa Jun 7 '16 at 11:39
  • \$\begingroup\$ Thanks Bruno - took all of this on board - especially sending the NewUser to the ActiveDirectory class! \$\endgroup\$ – Bassie Jun 9 '16 at 13:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.