Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We are using some utility methods in our company to simplify programming.

So we have following string extension:

public static bool IsNoE(this string s)
{
    return string.IsNullOrEmpty(s);
}

This is just for convenience and the intention of this question is not to discuss the sense or senseless of such methods (maintaining, ...)

The question is about the naming.

Some people think the method should be named in this way:

public static bool IsNullOrEmpty(this string s)
{
    return string.IsNullOrEmpty(s);
}

The argument for the first naming is:

  • It would not make sense to make extensions if they are not shorter to write.

The argument for the second naming is:

  • The only reason to add such extensions is just to support programming flow. (Writing a variable and then set the cursor back to the start to surround the variable with string.IsNull)

So why should I prefer one version over the other? Are there any naming conventions we can refer to?

share|improve this question

closed as primarily opinion-based by gnat, Kilian Foth, Bart van Ingen Schenau, Dan Pichelman, MichaelT Feb 15 at 2:10

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
I don't think this kind of null check is common enough to warrant a helper method beyond the existing string.IsNullOrEmpty. In my experience most null checks take the form if(x==null)throw new ArgumentNullException("x"). –  CodesInChaos Feb 12 at 16:40

3 Answers 3

up vote 18 down vote accepted

The first naming is just plainly wrong. Want a proof? What does the next piece of code do?

if (this.ah == PcX.Def)
{
    this.Z.SecN.Coll();
}

The second naming is ok. It's explicit enough, but not too long. It's the one which is used by .NET Framework, so other developers won't be lost.

This being said, don't create aliases: you create additional code which has to be tested and maintained, while it doesn't bring anything useful to the project.

share|improve this answer
2  
Not all aliases are created for the sake of having aliases. Eg. String.Format will throw an exception if the string can't be formatted (the number of "{x}" tokens is not right). Strings in the app I maintain are loaded in runtime because of localization. Somebody made a typo and translated a message as "sth sth {0)", the other bracket wasn't a curly one. It crashed the app. I replaced String.Format calls with an extension method that would recover from exception. Testing it didn't consume an awful lot of my time : ) –  Konrad Morawski Feb 12 at 17:03
7  
@KonradMorawski You method is not an alias since it provides different functionality than string.Format. –  Idan Arye Feb 12 at 17:33
3  
@Konrad - but how long will finding the next localization bug take? IMO it's better not to catch those exceptions, so that you can find the bugs earlier in the development/test cycle. –  Brian Reischl Feb 12 at 20:41

I actually use NullOrEmpty (on strings) as well as eg. JoinWith (an alias for String.Join).

The argument for the first naming is:

  • It would not make sense to make extensions if they are not shorter to write

Extension methods are shorter to write even if you do keep the original name, because you don't need to refer to the String class explicitly.

String.IsNullOrEmpty(foo)
foo.IsNullOrEmpty()

Isn't it shorter?

Or in my case:

foo.NullOrEmpty()

I find the extension method syntax even more handy for testing whether a string is not null nor empty.

Compare:

if (!String.IsNullOrEmpty(foo)) // double negation and not very readable, it's easy to miss the "!"

Versus:

if (foo.NotEmpty()) 

Having said that, I am 100% against cryptic naming such as IsNoE.

share|improve this answer
5  
Try reading that without foreknowledge of what the method really does. When I see if (foo.NotEmpty()) ..., I think "Hmm, that's gonna crash if foo is null.". NRE-protection should be obvious. And static methods shouldn't be made to appear instance-specific. –  Ross Patterson Feb 12 at 23:09

Seriously? Typing out method names is obsolete - if everyone had to type out System.Windows.Media.TextFormatting.TextSource.GetTextEffectCharacterIndexFromTextSourceCharacterIndex every time they used it, C# would be a dead language.

Fortunately the IDE does most of this for you, so length doesn't matter - clarity does however, so keep with the long version.

Any extension methods I create always go in their own namespace and are usually 'hungarianed' with 'Ext' at the end so I can clearly see its an extension (never want to spend time trying to figure out which class a method belongs to only to find it doesn't belong to any class! I figure it works well for interfaces (with an I prefix) and exceptions (with Exception suffix) to use this form for extensions.

share|improve this answer
2  
I don't understand the point you make in your last paragraph. The point of extension methods is to specify the behavior of classes (or usually interfaces) that you can't specify otherwise, either because (usually bad idea) the class is not yours and you can't modify or inherit it, or because it's an interface (usually good idea; classical example: LINQ). So conceptually, they belong to a class/interface like any non-static method, just that they are written somewhere outside (which shouldn't matter when you are using them). –  MainMa Feb 12 at 16:52
    
My point is that I go to the class and look at the methods and.. can;t find the one I wanted. So its just a hint to me that its an extension one. Conceptually they belong to the class like any other... Realistically they do not. They are a bit of an useful-but-dirty anti-pattern. –  gbjbaanb Feb 12 at 17:47
    
It it works for 'Exception' suffix, why not use the full 'Extensions' suffix instead of 'Ext'? Clarity matters, as you say. –  Jesse C. Slicer Feb 12 at 18:09
    
@JesseC.Slicer Because I'm too lazy when writing the original method out :-) –  gbjbaanb Feb 12 at 18:54
1  
A shorthand notation is not useful, even in cases like interfaces and type parameters if you have distinct syntax highlighting for them. Same with underscores on fields. If you aren't using IDE features, prefixes and suffixes are useful. Resharper can color just about anything differently. Don't misuse the tools provided to you. –  Magus Feb 14 at 0:19

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