|
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
|
|
|
|
|
I prefer this style of coding
try
{
someObj.SomeMethod();
}
catch (Exception)
{
Response.Redirect("http://www.codeproject.com/search.aspx?q=Object+reference+not+set+to+an+instance+of+an+object&sbo=qa");
}
|
|
|
|
|
Here we go . After so many years of coding, I've learned to cull back on the wordiness of the code. Still, I have a few wonder brothers who "read code so fluently" that things get opaque pretty quick. I try to stay away from the "//declare variables" nonsense and lean toward higher level explanations of code blocks.
One thing that will set me off is when people don't use version control. So, you'll get interspersed lines of code that are commented out with new lines of code that fix a problem. One leaves this in the source in case if you need to remember what you changed. FFS, use "show changes".
Charlie Gilley
<bold>Do not forget Jacques Hamel
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
There're times when the sort of commented old code crap can be useful. Like when you were given a source dump for an ancient MFC app that the customer wants an update to and find yourself going "WTF this pile of code looks like it was obsolete even when MFC was new. C with classes every once in a while is a revolting way to write C++." for weeks on end, finding that one file that never got cleaned up and is full of commented code to create X-Windows GUI components can be enlightening in an "OH. The original version of this dinosaur was apparently a C/Slowlaris application before being ported to the then new and shiny NT4 and MFC in the late 90s." sort of way.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Why try to penalize and educate the end user for the sins of a poor coder?
|
|
|
|
|
Because the next person the poor program sees after the end user is Jesus.
Edit:
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.
|
|
|
|
|
What's more disturbing is that C# still doesn't allow this:
if (!someObj) {...}
which would preclude them from having to come up with the bullsh|t "?" operator.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
modified 27-Jul-16 8:23am.
|
|
|
|
|
John Simmons / outlaw programmer wrote: bullsh|t "?" operator
More like boolsh|t in this case.
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.
|
|
|
|
|
If you implement the true[^] and false[^] operators, you can do something like:
if (someObj) { ... }
but you can't do:
if (!someObj) { ... }
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
The new approach (v6.0) is the null conditional operator, so you don't need to check for null.
someObj?.DoStuff();
|
|
|
|
|
I think that's what JSOP was referring to as the "bullsh|t operator".
#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
|
|
|
|
|
Oops, I missed that. Sorry.
|
|
|
|
|
Often, in cases like that, you could very well add a comment indicating why the ojbect reference would be null (or non-null). Not always, but often.
When studying code written by others, one of the questions I frequently as myself is of the kind "OK, so I understand that you can't Do Stuff on a null object, but in which cases is the object null?? A short end-of-line comment such as 'null if child hasn't been named yet' or 'null if cleanup actions are already performed' can be worth their weight in gold.
|
|
|
|
|
On the other hand, I most definitely hate the (much too common) C construct 'while (1) {...}'
In embedded code, you frequently have infinite loops, and in some software I was handling, I declared a const bool WW3 = false, and changed the loop to 'while (!WW3) {...}'. That really upset one of the other programmers, who edited it back to 'while (1)' with some really nasty comments in the SVN log.
I tried to adopt the CHILL idea: In CHILL, 'EVER' is a reserved word, and the 'official' way of writing an infinite loop is 'DO FOR EVER [...]'. So I set up a '#define ever ;;' so that I could write (in C) 'for (ever) {...}'. But even that was too much for this other programmer; he insisted that 'while (1)' is The Professional Way of writing an infinite loop. I let him have his will.
|
|
|
|
|
I have found that "50 Specific Ways to Improve Your C#" is really good, and one of the things that the author Bill Wagner points out is that your code should be self explanatory, and not require much in comments. Good variable names helps a lot.
|
|
|
|
|
 And good function names/class names. And a alear breakdown of code into bitesized pieces. Aptly named.
#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
|
|
|
|
|
Yes. That and using good encapsulation. On one project they passed all 3-d point vectors as separate arguments. They also had 1000+ line methods.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
