|
TheGreatAndPowerfulOz wrote: what the code is doing but not why
Because "check for null so we don't get a NullReferenceException when we access the properties of someObj" would be so much better!
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Yeah, that's worse
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
|
It gets better:
if (string.IsNullOrEmpty(something)) { ... }
|
|
|
|
|
Indeedly!
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
When no comments are actually better.
|
|
|
|
|
Yep.
My favorite:
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
I prefer:
#region Private Members
int thingy = 101;
#endregion
|
|
|
|
|
|
That is a line I would expect in a shell. A place marker.
|
|
|
|
|
Well, you've got a lot of "developer" responses, so far, so how about I add a "someone who has to explain to your customers' developers why your developers are such @rseholes" response.
You're absolutely right.
Because there are a thousand reasons for checking for null values, there are a thousand things that could be added to expand on what the statement does, e.g.
if (someObj != null) {...}
if (someObj != null) {...}
if (someObj != null) {...}
There's almost never an excuse for a line of doc that says exactly the same as the line of code.
If the who/why/where/when/what is not needed, then the doc is not needed.
If the who/why/where/when/what is needed, then the doc is needed, and just keep in mind that some other poor b*st*rd has to try and make your program useful.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I am one of the other poor b*st*rd now.
The original developers think their code is so beautiful and wonderful that no comment is needed to explain. They think I should ask if I do not understand. It will take longer than my lifetime to finish project this way.
|
|
|
|
|
You have my deepest sympathy.
'PLAN' is NOT one of those four-letter words.
'When money talks, nobody listens to the customer anymore.'
|
|
|
|
|
My sympathies. Been there, hated it.
Look at the bright side, though: if the job were too easy, you'd get bored.
Mind you, the jury's still out on which of bored and tearing-your-hair-out-in-frustration is worse.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I really dislike code comments in general[^]
Currently, I have a coworker who writes comments like:
int i;
i = 42; He doesn't do it all the time, but such comments are common practice.
Learn to friggin code so you don't have to remind yourself of how to declare and assign a friggin variable!
|
|
|
|
|
Sander Rossel wrote: Currently, I have a coworker who writes comments like: Perhaps he used to teach first level coding in high school.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
He never did coding in school, maybe he's trying to make up for it?
|
|
|
|
|
I was always taught that code comments are to describe a process your code is doing, if it is complex and not easily understood from the existing code base - otherwise, don't comment. It has served me well, all these years, so I stick with it...very minimal commenting in my code.
|
|
|
|
|
Bah!! find something to complain about for Betsy's sake! If some lonely sole feels compelled to write a novel between the lines of code and feels it helps them remember what the heck they are doing why does it bother you? Granted 'Good' comments will help someone else down the road. Let us understand people, we comment as a CYA first and foremost and therefore this is an exercise in self preservation; consequently self serving.
|
|
|
|
|
blow it out your ass.
|
|
|
|
|
Not everybody can be a master of the obvious.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Well, gosh ... if I only had a Baht (about 2.86 US cents) for every time I've written: if(whatever != null) ...
However, is it, perhaps, useful to distinguish two scenarios:
1. checking for null when there's no need to throw an error if the whatever is null, and, the code context makes it absolutely clear what's going on.
2. checking for null when you absolutely should throw an error on null
I recognize there are "purists" who would like to see you throw errors in all cases.
And, how about this: disclaimer: this is an experiment I did a while ago; I am not indirectly expressing the opinion that anyone should use something like this:
public static class ErrorExtensions
{
public static bool IsNonNull<T>(this T refobj, bool throwerror = false, string message = null)
where T : class
{
if (refobj == null)
{
string mess = string.Format("instance of {0} is null: {1}",typeof(T).Name, message);
if (throwerror)
{
throw new NullReferenceException(mess);
}
else
{
#if ErrorsToConsole
Console.WriteLine(mess);
#endif
}
return false;
}
return true;
}
}
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
modified 27-Jul-16 4:13am.
|
|
|
|
|
IsNotNull?
Also, you should not be purposely throwing an error from an extension method, as part of some divine plan. Just check if it is null or not, that is all. Leave the implementation to the calling party - this helps with code reuse (I may not want to do a console.writeline ).
My 2 unsolicited cents on your post.
|
|
|
|
|
Christ! Can't you read?
He wants 2.86 cents.
Michael Martin
Australia
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."
- Mr.Prakash One Fine Saturday. 24/04/2004
|
|
|
|
|
Well, I am afraid someone took me off the "divine plan" update service some years ago.
Please note:
1. the code will throw an error in the Extension method only when the 'throwerror parameter is 'true, and, of course, the instance of the generic parameter T (constrained to Type 'Class) is null.
2. the code will only call Console.WriteLine when the compiler directive '#define ErrorsToConsole is included at the start of the file. One would expect this to be present only in the developer's code who is using the source.
Again, keep in mind this is only an experiment.
I gladly accept your 2 cents !
cheers, Bill
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|