Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 '14 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.

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 '14 at 16:40
up vote 21 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)

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
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 '14 at 17:03
@KonradMorawski You method is not an alias since it provides different functionality than string.Format. – Idan Arye Feb 12 '14 at 17:33
@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 '14 at 20:41

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
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 '14 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 '14 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 '14 at 18:09
@JesseC.Slicer Because I'm too lazy when writing the original method out :-) – gbjbaanb Feb 12 '14 at 18:54
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 '14 at 0:19

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.


Isn't it shorter?

Or in my case:


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


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


if (foo.NotEmpty()) 

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

share|improve this answer
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 '14 at 23:09
I feel like this is a misrepresentation of what people mean by "less code is better code". you can't really drag it down to statement-level and say "9 chars is better than 12 chars!", it's about more subtle things than that. amount of symbols in scope, types used, statements used and so on. also, as a new developer, when you see something like str.NotEmpty() you have NO idea what it does. does it check for null? and if it does, does it throw an argument exception? or does it return false? is whitespace empty? string.IsNullOrEmpty(string) is well documented and understood by all .NET devs. – kai Jul 15 at 14:30

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