 |

|
Nice tips, Thanks for sharing them.
|
|
|
|

|
Use Path.Combine over "//"
Use String.Concat if not interested in String.Format
Carefully choose params
Always try to use Using(){} block
Try to make sure if you need Dispose pattern
Use static carefully
Never make SqlConnection global/class scope.
Play with CommandBehavior w.r.t Sql operations
Always suffix Delegate and Event respectively for custom delegates and events respectively (as part of naming thingy)
Never use magic strings/numbers instead use resources
prefix private var names with _
Choose carefully between StringBuilder and string (yes you have mentioned it, but some times not always SB is good enough)
Carefully understand the features of out and ref and use it appropriately
Do not use too much of virtual functions (some times it may cause performance overheads since they cant be inlined by JIT
Carefully choose Const vs readonly
Understand how valuetypes and ref types works internally (indepth), perhaps read Eric lippart blog post on same
Carefully understand diff between Linq and foreach. Not always Linq is preferable
P.S: most of the above things have picked up frm my memory and earlier tweets
|
|
|
|

|
Nice points
I propose this for updation
|
|
|
|

|
Thanks, your valuable votes are appreciated
|
|
|
|

|
Thanks for sharing those.
|
|
|
|

|
Your welcome, your votes are much appreciated too
|
|
|
|

|
"Never use a name which begins with numeric character"
That's not a convention, that's a requirement of the language. And as such, it really shouldn't be there because you can't even compile code with a variable named that way.
|
|
|
|
|

|
I agree with your comments. What I meant was not the type you have given as an example but about using the first letter as capital and vice versa. I find that using all lower case and as I said befor identifying classes as class_something; a form as form_something, looks neater and easier to follow.
Thanks for your response.
|
|
|
|

|
Any one newer to this C#, can knowing something more and improve his work performance better.
|
|
|
|

|
Hello Kunal,
I have seen this sort of advice in the web and even in the print media. You state among other things:
◦Always use Camel or Pascal naming format
◦Avoid all uppercase or lowercase names
But why?????? You nor anyone else has told why this convention should be followed; any particular reason? I have been programming from 1972 and is adept at most languages including machine codinge (the hardest of them all!), assembler up to present day C# etc. When programming I have gone against all norms (to figure out what issues I'll be faced with) once in a way and never found an issue. I usually prefer to name say for example all forms as "form_something" all classes as "class_something" but have had no issue. I try to give a meaningful name in alphabatical order so I know which forms are called first or what was developed first. I have my own reasons for doing this. If the project is large with many forms and classes it is easier to locate the class or the forms or whatever because everything will be in one place ina an organised manner. I have tried your advise which was given in a print media but found I waste time looking for a form when I need to.
I would welcome your reply. Your article was nevertheless interesting.
Ananda
|
|
|
|

|
These are the common practices. If you write in all upper/lower or in any type of naming convention, there will not be any issue directly. Your code will still compile & run. But think as a reader. If I am not following proper naming convention, it will be very difficult for you to identify any control, properties, class etc.
Just for an example, "mYpErs0n". Can you tell me what is this? Is it a class, property, member variable or something else? You will say, it is really very difficult to identify from the above statement.
Exactly, I was telling the samething to you... Hope you understand it now.
|
|
|
|

|
not an article - just a checklist
|
|
|
|

|
Yes, this is not an article. Where did you see it as an CP article? It's a Technical blog feed added to CP as Technical Blog post. It is just a list, but I described them in separate article.
|
|
|
|

|
Simply because they give no basis for the recommendation. All too often I've worked with programmers that "always/never do that" without knowing why - other than it was on some list of things to (not) do. The list would be much more useful if it gave explanations (like the comment on String.Concat).
Effective C# and More Effective C# are two books that have recommendations with really good, clear reasoning behind them. Highly recommended.
|
|
|
|
|

|
Why Prefer Runtime Constants over Compile time Constants.
I can't se the resoning for that.
|
|
|
|
|

|
I think this is a useful start point for beginners and not-so-beginners to become a good programmer instead only be just one coder.
|
|
|
|
|

|
With one note: you'll never study well, until you step on your own rakes - then you catch WHY that advise made. And with one exception: design patterns are evil. For professionals it's useless, they generate these patterns from head in seconds. For novices they are useless, since they don't know what and where to apply properly. Moreover: FIRST is task, SECOND is solution. Instead all those articles first push damn 'solutions' and next people think where to apply it. Keep well!
|
|
|
|
|

|
A great set of comprehensive coding standards. They [almost] all make sense and are well thought through.
|
|
|
|

|
Thanks for your feedback and the vote. Appreciate your suggestion in the earlier post.
|
|
|
|
|

|
I think your recommendation is great, but can be optimised. If it's possible to write clear, maintainable code using String.Concat, we should prefer that over String.Format.
The optimisation is apparent when you look at the code (in Reflector, for example). String.Format will always end up in this overload:
public static string Format(IFormatProvider provider, string format, params object[] args)
{
if ((format == null) || (args == null))
{
throw new ArgumentNullException((format == null) ? "format" : "args");
}
StringBuilder builder = new StringBuilder(format.Length + (args.Length * 8));
builder.AppendFormat(provider, format, args);
return builder.ToString();
}
whereas String.Concat ends up here:
private static unsafe void FillStringChecked(string dest, int destPos, string src)
{
int length = src.Length;
if (length > (dest.Length - destPos))
{
throw new IndexOutOfRangeException();
}
fixed (char* chRef = &dest.m_firstChar)
{
fixed (char* chRef2 = &src.m_firstChar)
{
wstrcpy(chRef + destPos, chRef2, length);
}
}
}
The unsafe string concatenation will always be faster under the hood, if only slightly, than creating a StringBuilder and calling StringBuilder.AppendFormat. And that String.Format always ends up using a StringBuilder also means that we should only use String.Format when it allows clearer code than a StringBuilder.
|
|
|
|

|
Good Suggestion with explanation. Have a +5 from me.
|
|
|
|

|
Sorry, I don't quite agree with some points.
|
|
|
|

|
It will be better if you can tell me the points and reason.
|
|
|
|

|
Hmm, re:"Always prefer the foreach(…) loop", I thought foreach incur a poorer performance than for. And re:"Choose between Equal and Equal(==) operator", which one is the prefer one? Hehe... thanks.
Regards,
TungLeh
Regards,
Cody
|
|
|
|

|
Just wait for some days...
|
|
|
|
|

|
Yes i too do not agree on always using foreach. But compared to Linq and foreach, then one must carefully choose which of these is best considering the performance hits by frequent code hits and differed execution stuffs.
Equals vs == operator varies for valuetypes and ref types. So you gotta understand which one is right fit for what type your trying to compare.
|
|
|
|

|
Every item listed makes me wonder: why? The article is not (yet) helpful, but I'll be looking forward to the extended one.
|
|
|
|

|
Emile van Gerwen wrote: Every item listed makes me wonder: why?
Appreciate your time for reading this Technical Article. It is not an article but a blog post fetched in CodeProject to get some positive feedbacks from my readers for the upcoming article, where I am describing each one of them with examples.
Emile van Gerwen wrote: The article is not (yet) helpful
Agree. It is just to get some additional points from my readers for the original article.
If you have some valid suggestions, please don't hesitate to share it here.
Emile van Gerwen wrote: My vote of 2
I don't think this is any how require to downvote the article where I am seeking suggestion from you.
|
|
|
|
|
|

|
leidenbach wrote: no examples
Did you read the complete post? If you read it, you will not downvote my article asking examples.
|
|
|
|
|

|
I learnt some points which i don't know before, thanks.
|
|
|
|

|
pavan kumar muvvala wrote: I learnt some points which i don't know before, thanks.
You are welcome. Please wait for the actual article where I will describe each on of the points.
|
|
|
|
|

|
Good advice but it's far too brief and far too reduced to be overly helpful. Especially in cases of: "Decide between" "whenever required" "when you need them" "Chose[sic] between" -- I can tell what you're getting at, but these statements are meaningless. Choosing/using/deciding is the definition of design. I don't need you to remind me to make choices -- these are decisions I can't help but make.
This should never have been a published article. This should have been your personal notes before drafting a real guiding force. You obviously have the knowledge and experience, but to me this attempt screams "lazy."
I'd like to see you back up each of these points with some facts. The only reason I agree with your points is because I already have the same knowledge. It's not helping me -- we already agree. For someone without the same knowledge: it's not helping them, because it's just a list of DOs and DON'Ts without backing.
I'm voting "3" because it's a draft of what could be great, not because I think it currently is.
|
|
|
|

|
Thanks for your feedback. Yes, it is not an article but a blog post that fetched in CodeProject. I am currently working on the actual article where I am mentioning the reason behind each on of the points. It is taking some time to prepare the article & publishing it to my readers. This is already mentioned above.
Please be patient for sometime to read the complete article.
|
|
|
|

|
I saw you mention that you're working on a better version, but I haven't yet seen it so I and others can only vote on what is present.
If you show me eggs, cocoa, sugar, flour, and milk then say you're going to make a cake, I'll still be unimpressed with your ordinary stack of ingredients even while I look forward to your chocolate cake.
|
|
|
|
|
|
|
|
|
 |