HN Explorer

A matter of style in C#

2 points by annymsMthd ↗ HN
Hello I am a c# developer. I am currently close to being hired by avid HNer but I have a couple of things with my coding style that I need to correct. I did not take any college courses on computer science and everything I know about c# and the .Net framework I have taught myself. I was wondering if anybody had any good articles or advice on writing clean and understandable code. I have been working professionally as a c# developer for almost 2 years and everything I have done has been solo. Learning how to write clear and concise code is a must and I would greatly appreciate any advice offered.

13 comments

[ 2.6 ms ] story [ 32.3 ms ] thread
icey
Well, if you're not idiomatic with C# yet, that would be the very first place I'd start (by that I mean you know why you'd use StringBuilder vs. string concatenation, etc).

After that, make sure you're good about commenting code that isn't immediately obvious.

From that point, I'm afraid we'd probably need some samples to see where you might be going wrong or right.

annymsMthd
I definately know some of the inner workings of.Net, such as using StringBuilder compared to string concatenation. Some of the things I need to know is what is an acceptible name for a variable based on its scope. For instance currently to describe a private variable belonging to a class I will prefix it with an underscore. Is there a universal way of denoting varibles by scope?
[deleted]
(comment deleted)
icey
I'd try taking a look at "IDesign C# Coding Standard, for development guidelines and best practices" from here:

http://idesign.net/idesign/DesktopDefault.aspx

(This is the direct download link: http://idesign.net/idesign/download/IDesign%20CSharp%20Codin...)

ScottWhigham
I would second this - it has a lot of good info for C# folks.
annymsMthd
This is an excellent article. I follow alot of the guidlines already but there is some important ones that I am missing. Thank you.
profquail
I don't think there's a universal way, but what I usually do is:

- For private class fields, I use an underscore with camelcase, starting with a lowercase letter, e.g.:

private static int _id = 12345;

- For public class fields, properties, methods, etc. I use camelcase, starting with an uppercase letter, e.g.:

public double Determinant() ...

- For method parameters, I use camelcase, starting with a lowercase letter, e.g.:

public void Foo(int bar, ref string helloThere)

I think this is also the style that Microsoft uses internally, and it makes it easy to see where your variables came from.

Novash
The standard (citing from memory) is to use Properties in uppercase (PascalCase) and fields in lowercase (camelCase) with NO prefix whatsoever but preceed them with "this." whenever referenced. parameters are also lowercase (camelCase) with NO prefix whatsoever and are thus difference of local variables by the absence of the "this.". However, this doesn't answer the static fields and Properties...
asimjalis
Can you understand the code you wrote a month ago? Also, do you use meaningful class names, method names and variable names? Beyond this maybe you want to post some of your code here and see what feedback you get.
annymsMthd
I have no problem understanding my code, even the stuff I wrote a year ago. I may not agree with the way I coded some of what I wrote before but it is easy to follow my own logic.

When naming variables I try to give them meaningful names but sometimes within the scope of a method I will assign single letter names to variables just used within the scope.

I am peticular about not posting code that I have done for my employer but perhaps I can solve a generic problem and post the code for that. My biggest problem is that I have not had to work with another coder before and I need to learn how to properly communicate my logic and ensure that the logic is the most efficient possible.

DanielStraight
I would highly recommend reading Code Complete 2 by Steve McConnell.
annymsMthd
Awesome suggestion, thank you.

From scanning through the Chapter on design I got this quote: "This paradox implies, essentially, that you have to 'solve' the problem once in order to clearly define it and then solve it again to create a solution that works."

It reminds me of advice I have gotten from someone before, write code to solve a problem then scrape it and rewrite it.

ScottWhigham
I like the book "Effective C#: 50 Specific Ways to Improve Your C#" - it has a lot of good tips in quick, easy-to-implement-in-36-hours-or-less format. ISBN: 0321245660