|
Can someone direct me regarding coding standards for C#?
I am new to C# and am currentyl moving to C# from VB .NET
Most of my previous programming experience has been within procedural programming languages so OOP is fairly new to me.
C# with curly brackets is entirely new to me.
To give you some idea of how I code I have included a simple code snippet below.
Comments suggestions etc gratefully received(please be gentle or I might return to VB .NET )
<code>
class Prime
{
double testNum, testLimit;
public bool isPrime(double numIn)
{
testLimit = numIn;
testNum = 3;
if (testLimit % 2 == 0)
return false;
while (testLimit > testNum)
{
if (numIn % testNum == 0)
return false;
testLimit = numIn / testNum;
testNum += 2;
}
return true;
}
}
You always pass failure on the way to success.
|
|
|
|
|
GuyThiebaut wrote: Comments suggestions etc gratefully received(please be gentle or I might return to VB .NET)
I think everyone will be nice, NO ONE wants you to return to VB.NET
Everything looks good to me, I have one one suggestion.
GuyThiebaut wrote: if (testLimit % 2 == 0)
Logically, it doesn't matter. I always find it best though to put the constant on the left hand side of a comparision operator. Example:
<code>if (0 == testLimit % 2)</code>
or
<code>
if(string.empty != strMyString)
{
MessageBox.Show("This string contains stuff!");
}
</code>
Like I said, it really doesn't make any difference, but it makes your code a lot more readable, and if someone else happens to be working inside your code, it will give them a better understanding of what is going on. Just my $0.02
Good luck in your quest to learn C#, I think you will find it very similar.
I get all the news I need from the weather report - Paul Simon (from "The Only Living Boy in New York")
|
|
|
|
|
Thanks Justin,
Will follow your suggestion with regards to the positioning of constants within comparisons.
I'm already beginning to like the simplicity and lack of wordiness of C#.
You always pass failure on the way to success.
|
|
|
|
|
Justin Perez wrote: I always find it best though to put the constant on the left hand side of a comparision operator.
That's a left over from C/C++, where the boolean type is numeric. Putting the constant first keeps you from accidentally using the assignment operator instead of the equality operator. In C# the boolean type is not numeric, so there is no need to do this.
Also, putting the constant first is only more readable if you are very used to reading it exactly that way. The logic way to write it is to not swap them around so that the constant is first.
---
single minded; short sighted; long gone;
|
|
|
|
|
IMHO, it is preferable to place every block of code within curly braces. It aids readability despite not being syntactically necessary. Also, I would declare each variable on a separate line.
Paul Marfleet
|
|
|
|
|
Thanks,
pmarfleet wrote: it is preferable to place every block of code within curly braces
I take it you are referring to the if statements.
I agree with you - I sometimes take shortcuts; however it helps others, reading my code, to avoid those shortcuts.
You always pass failure on the way to success.
|
|
|
|
|
That's right. For instance, within your loop it isn't immediately obvious which statements are dependent on the result of the if statement and which aren't. Placing all dependent statements within curly braces aids readability, even if this is only a single statement.
Paul Marfleet
|
|
|
|
|
GuyThiebaut wrote: I sometimes take shortcuts; however it helps others, reading my code, to avoid those shortcuts.
Not only does it help others, but it will help you in the long run as well. I have seen all too often someone (even the original author) modifying code sometime later (months to years), not paying attention and adding a line to an if block. The problem here was that the if block originally was a single line with no braces. The new line was added, and significantly changed the behavior of the code. Had the braces been there to start, it would have been completely obvious where the line was going and that it was properly inside the if block.
|
|
|
|
|
The variables that you declare in the class should be declared inside the method instead.
As the method is not using any data from the object instance, it should be static.
Method names are usually written in PascalCase, i.e. IsPrime .
To always use brackets around a block makes the code more readable, i.e:
if (testLimit % 2 == 0) {
return false;
}
If the code in the method has a singe exit point, it's easier to follow.
---
single minded; short sighted; long gone;
|
|
|
|
|
Thanks for all the information and help
You always pass failure on the way to success.
|
|
|
|
|
You can also look at the Framework Design Guidelines (either on MSDN or the printed book). These are the design guidelines Microsoft created after .NET 1.0 was released.
The important thing to remember about code style and standards is that they:- are guidelines
- are not set in stone
- should be consistent
- should be flexible enough to adapt to new languages and technologies within those languages
|
|
|
|
|
Thanks,
I get what you are saying regarding bracketting.
In some of the procedural languages I have programmed I have seen people using what are called "in-line ifs".
I have always avoided them, unless there is no other solution, for precisely this reason - the logic can be misunderstood or lost and new code added can cause all sorts of problems at testing (we do all test code don't we...).
Thanks for the reference.
I will look at this.
As you say standards need to be flexible as in my experience some businesses have their own in house rules on coding standards.
When I was trained in COBOL (no I'm not a Grandfather yet...) the trainers would get a ruler and measure code indentation, to the centimetre, on our code printouts
You always pass failure on the way to success.
|
|
|
|
|
i got a realy strange issue with invoking code on a multi threaded application , it happens on thins function below:
<br />
private void closeForm()<br />
{<br />
if (this.InvokeRequired)<br />
{<br />
ShowFormCallback d = new ShowFormCallback(closeForm);<br />
this.Invoke(d, new object[] {});<br />
}<br />
else<br />
{<br />
try<br />
{<br />
goform.Close();<br />
}<br />
catch(Exception e)<br />
{ <br />
Console.WriteLine("Cant close the damn form " + e.Message);<br />
}<br />
}<br />
<br />
}<br />
<br />
}<br />
The Error is:
"Cross-thread operation not valid: Control 'player2' accessed from a thread other than the thread it was created on."
although on debug i see that when the closeForm() is executed
this.InvokeRequired has a "false" value.
and yet when the line: "goform1.Close();" is executed i get cross-thread operation not valid.
how is this possible, i have used this technique (given by the MSDN) in order to avoid such errors several times and never had problem with it,
so what could be the cause of such a thing?
Net
|
|
|
|
|
What does "goform.InvokeRequired" return? That is the control you are executing a method on, so it's really up to that control to determine if it needs an invoke.
|
|
|
|
|
oh oops , my mistake , i wrote this.InvokeRequired instead of ,
goform.InvokeRequired , now it returns 'true'
Net
|
|
|
|
|
Can Fibonacci Series be generated with the help of operator overloading?
|
|
|
|
|
It would for exampel be possible to make a class representing a number in the fibonacci series and overload for example ++ to give the next number in the series.
I can't think of any reason this should be done, but as long as the question is if it could be done, then the answer is yes.
|
|
|
|
|
Sure - it could even be done with anonymous methods if you like. However, wouldn't it have been better for you to actually try it out before posting a question? That would have answered it for you - and you'd have advanced your coding skills just that little bit more.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
It's possible, but certainly not practical.
|
|
|
|
|
Hi all,
Library is coded in C#.
Here are the conditions:
So if I've got an array list of MyObjects_;
Each MyObject_ contains a value
There are only 4 types of MyObjects_ (Ie. obj1 = 6, obj2 = 4, obj3 = 3, obj2 = 2, obj1 = 1);
I have an input value of (MyObjects_)input_ = 21;
The array list size is unsorted and is an undetermined size until runtime.
What's the logic to determine the most accurate combination of objects to result in the combination of (obj[i] == input_)?
Thanks in advance
Humble
|
|
|
|
|
Just looking for the logic, and not the code.
|
|
|
|
|
humblepgmr wrote: So if I've got an array list of MyObjects_;
What's the deal with the underscore?
humblepgmr wrote: There are only 4 types of MyObjects_ (Ie. obj1 = 6, obj2 = 4, obj3 = 3, obj2 = 2, obj1 = 1);
What do you mean by "type" in this case?
humblepgmr wrote: What's the logic to determine the most accurate combination of objects to result in the combination of (obj[i] == input_)?
Could you specify in what way any combination would be more accurate than any other?
---
single minded; short sighted; long gone;
|
|
|
|
|
1) How does an input value of 21 fit into a context of an array list containing 4 different types, none of which are 21?
2) What is an "accurate combination of objects"?
3) What is now i in the "obj[i] == input_" part? And index I guess... but of what?
4) What is that trailing underscore doing everywhere (not relevant for your question as such I guess, just wondering).
|
|
|
|
|
Hi,
I have dug through MSDN regarding using a destrutor and Dispose method.. Now I am confused, whats the difference between the two.. They both can be used to release unmanaged resources, right? So whats the difference?
Regards,
Blumen
|
|
|
|
|
In c# there's no such thing as a deterministic destructor like in c++. Instead you have a non-deterministic finaliser. If you include a finaliser in your class, when you have finished with the object it will be placed in the finalisation queue, and the finailise method will get called next time garbage collection is run.
This means that your objects may hang around for quite a while, hogging up memory, or holding onto resources, so to help things along we use the dispose pattern which allows us to ensure that objects gets cleared up quickly and finislisation doesn't have to happen. The dispose method should clean up all resourses, and supress finalisation, while the finaliser method should only clear up _unmanaged_ resources. This is becuase the finaliser may get called much later on, so other managaed resources may already have been destoryed, so you mustn't risk referencing them again.
You can then call the dispose method manually when you have finished with the object (or use the "Using" keyword to ensure it gets called)
To read about the dispose pattern check out this site:
http://msdn2.microsoft.com/en-us/library/b1yfkh5e.aspx
See this page for more about the "Using" keyword
http://msdn2.microsoft.com/en-us/library/yh598w02.aspx
Hope that helps.
Simon
|
|
|
|