jasonbock.net

i_dont_like_underscores_in_code

I tried to put my comment into this post, but I couldn't tell if it was accepted or not, and I've seen this kind of API style popping up more and more lately, so...my post is born!

The thing about having a public .NET API using underscores is it doesn't fit the recommended coding style. If you're in Eiffel, that's actually what you do - in fact, you use upper-case and underscores (e.g. GET_CUSTOMER). But in .NET, public APIs should be Pascal-cased with no underscores - e.g. GetCustomer. CodeAnalysis rule CA1707 helps enforce this style as well.

I actually like the interface that Jean-Paul came up with. I've seen other "fluent" designs pop up lately, and they all seem to use the underscore approach. The idea is nice...just follow the .NET style.

* Posted at 08.27.2008 09:12:49 AM (Last Update: 08.28.2008 09:07:05 AM) | 4 comments | Link | RSS *

Comments

# Tests, from Donn at 08.27.2008 10:59:14 AM

I agree with your statement. I follow the same CA17107 as well. I feel its the BEST way to format code.

However, when formatting my unit tests I like to use the underscore approach. It allows me to read my tests a lot easier and allows for exportation of tests.
Gold_Customer_Should_Get_10_Percent_Off_Order_Total_Before_Tax
is super easy to read. The big plus about this is that you can use a snippet written by Bellware (I think he wrote it - or you can write you own) that will pull out the test names and replace underscores with spaces and place them into a text doc. This is one approach to fulfilling the need of QA or the C-Level who says "You wrote 200 tests? Pfffft, whatever ... and what exactly do your 200 tests do?" BLAMMO... hit the macro and extract the test names (which are behavioral) and give him the text doc or send it to him in an email. This isnt a silver bullet, but it helps.

# Understood, but..., from Jason Bock at 08.27.2008 11:26:56 AM

I always aim for consistency. I don't like making style changes. That's why I wouldn't change the rules for unit tests. I get your point about the macro, but if I write GoldCustomerShouldGet10PercentOffOrderTotalBeforeTax, I think that's descriptive enough. Sure, having the space in there helps for the specific scenario you just mentioned, but it doesn't warrant having a different style in the code base.

# Misconception, from Ivan Porto Carrero at 08.28.2008 04:25:14 AM

I think there is a misunderstanding here.
In the DLR based languages you do use the languages idiom. By coincidence in C# and VB these are camel cased. In IronRuby they are not. but if you want to use IronRuby code from C# you can use the proper naming conventions that belong to that language.

# Clarification, from Jason Bock at 08.28.2008 09:03:19 AM

In .NET, the standard is PascalCase for public members (e.g. method names, class names, etc.) and camelCase for method arguments. So that's why VB and C# follow this. When you're in IronRuby and IronPython, yes, you still follow the language's style history. There's also mappings that go on between these world. I saw this years ago when Eiffel had their EIffel.NET product (not sure if they still have it). The .NET types would have the Eiffel style convention and IIRC a compiled Eiffel.NET type would have the right .NET style if used in C# or VB.