|
I didn't say it was. I'm well aware of .NET and what it is and isn't. I worked on VStudio Whidbey, FFS.
Member 7989122 wrote: Do you ever "blame" the intermedate gcc format for front ends that doesn't optimize the code much?
This isn't about blame. This is about stating a fact. None of the compilers shipped with any flavor of .NET that targets any flavor of the CLI optimizes very much, if at all. And when one writes code it pays to know what the compiler is actually doing with it, lest someone make some bad design decisions (like trying to use enums for state machine internals)
It's all punted to the JIT, and the JIT just doesn't optimize much.
You can wrap a response to that in as many words as you like, but it doesn't change the facts on the ground.
And it won't get me to start using enums in my state machine code internals.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
If it ain't broke, fix it 'til it is.
Oh, hang on - save your ass, you say?
|
|
|
|
|
Don't return null. Throw an exception instead.
Removes need to null check everything.
Hopefully give a more meaningful error when a problem occurs.
|
|
|
|
|
Yikes! I'd hate to write code that way but to each their own.
Null is often as not, a valid value, and not even a symptom of some sort of error.
No way do I want to wrap my calls to a function that is expected to have null as one of its values with:
object result;
try {
result=Foo();
}
catch { result = null;}
more bugs, extra slow, and for no reason.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Different use cases.
I’m stuck debugging an app that is crashing because NULL is not a valid value.
A part of what makes programming fun (?), is the various ways to solve a particular problem.
|
|
|
|
|
ha!, i can understand your sentiment. I recently developed a caching JSON entity framework for accessing TMDb's REST API and all their JSON fields are marked optional, which means potential for nulls everywhere. It made errorhandling hell.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
TrinityRaven wrote: Don't return null. Throw an exception instead.
Sure, if it really is an execption.
But I don't want to handle, say, a person who has no middle name as an exception just because his middle name is null. Or a person without a spouse, or without children.
I can guess your reply: The middle name should be a zero lenght string, not null!
In some cases, a zero-size value may be conceptually correct. Far from always. There is a semantic difference between something being there, regardless of size, and something not being there. You easily end up with testing on nonzero size rather than null, which may in some contexts be both confusing and give more complex code. And it might require more data space.
I guess that you still accept null checks in loops and list traversals, as long as as no function calls are involved: "while (nextobject != null) {process it and determine the next object}" is perfectly fine ... until "determine the next object" becomes so complex that you factor it out as a function. By your rule, the while condition can be dropped; you will threat the end of the list as something exceptional that requires exception handling.
But it isn't "exceptional" to reach the end of a list in list traversal! If you do not process all elements but factor out the code that decides which elements to skip, that doesn't make the end of the list more exceptional.
I started learing programming when access to computer resources were scarce. Maybe that was one reason for why many of the first hand-ins were to be made in pseudocode: somewhat formalized English, but remote from coding syntax. Actually, if we got even close to a programming language syntax, the professor used his red pen: Why do you restrict it this way? Is there, or isn't there, a semantic difference between this kind of value and that kind? Is it appropriate to add #apples to #oranges here - you tell that there isn't?
I like pseudocode. It relieves you from language syntax, lets you describe the problem solution at a logical level. If I had it my way, every software design should include a documentation of the solution logic in a form of pseudocode completely removed from any programming language. It should be equally valid if it was decided to re-implement the C++ system i Fortran, or Visual Basic or Erlang or APL. Even if the system is never reimplemented in another language, I think that kind of documentation would improve code quality, by focusing on the problem solution rather on syntax details.
|
|
|
|
|
I didn't say don't use null. I said don't return null
NULL can be useful in a data structure, and to use your example in a Person of Name class having null for the middle name could be (I won't say "is") better that "NMN" (No Middle Name) or similar.
The question is what helps save [my] behind.
There are times when "yoda conditionals" make sense. There are use cases where they don't. I didn't specifically chime in on that discussion because I can see both sides and use (or not) depending on readability and what is being tested for.
Returning null, in my not so humble opinion, is a code smell. Using null in a data structure is not.
But ultimately, it depends on the team's (or single developer's) style and agreements. And do you accept the related overhead - null checks (or Elvis operator), or try ... catch.
|
|
|
|
|
TrinityRaven wrote: I didn't say don't use null. I said don't return null
Yes, that's exactly what I pointed out in my loop example: You accept a loop to run until the next element is null unless determining the next element is so complex that it has been pulled out as a function.
If you do that, pull it out as a function, and follow your rule, then the function cannot return the next element the way the simpler inline code (with no function definition) did. The function would have to raise an exception when reaching the end of the list, and the call to the function would have to be wrapped in a try-catch, the exception handler would treat the exception as "ok, so then we set next element to null, so that the while check will terminate the loop", rather than simply accept a the next element as null from the function.
I find that to be an outright silly way of coding - and I don't think that you seriously suggest it. "don't return null" wasn't meant that absolutely; there are cases where communicating a null value to a calling function as something perfectly normal is ... perfectly normal. I say: That happens quite often. You say: OK, in some very special circumstances, like the one with "next object", you could accept it, as an exceptional case. - The question is where to draw the line. But the line is there.
I have seen code that tries to hide nulls by returning pseudo objects: If you ask for, say, a person's spouse, you never receive "null" or "none" or "void", but a person object that has a special identifier member like "no person". Testing for the returned person object being a person with a "no person" identifier is not more convenient by any criteria. You might forget to do that check, too, an reference attributes of this person object, that it doesn't have, because it is a "no person".
Finally: You make an absolute assumption that the called routine remembers to always define the return value to something non-null. I have had cases where the null check on the return value revealed errors in the called function, in a "graceful" way. If my programming style had been "You don't have to check for null returns, because functions do not return null", the error would have been caught much later.
Nowadays, we are using static code analysis tools that do a very thorough check on pointer use. If there is any chance whatsoever that a pointer is null or unassigned when dereferenced, you receive a warning. I have experienced flow paths with 20+ decision points, running through four levels of function calls, telling me that "What you did (or didn't do) there, at the start of the chain, might lead to the pointer you dereference at the end of the chain is null, if this and that and that condition is fulfilled". (And, if I make no use of the returned value, the analyzer is quiet - there is no danger.)
|
|
|
|
|
"Registered Nurse" to remember \r\n
|
|
|
|
|
My Mantra: "I'm too old for this ***t"
|
|
|
|
|
I'd be curious to see an expansion of "this ***t".
It might very well have great overlaps with my list. I know very well the feelings that you are expressing.
|
|
|
|
|
This catchy phrase was uttered by Roger Murtaugh (Danny Glover) in the original Lethal Weapon movie and then carried to the rest of that franchise.
|
|
|
|
|
|
i hear you
Usually it's my code that I want to be in a hurry. =) Go! Compute that LALR(1) table! Factor that grammar!
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Hmmmm... "Hurry", maybe that's a name I should consider for my new car. "I'm in Hurry, don't hinder me".
(My present one is a red Ford, so I call it Robert.)
|
|
|
|
|
Mostly I just follow the Babylon 5 mantra. I also often catalog the stupidity I'm about to do prior to doing it.
|
|
|
|
|
Write once, read multiple
eg, in SQL - if you're thinking "a" is a valid alias for Account table then think again. Account is not a long word. Make it meaningful. If you have AccountProductMemberElephant table then APME is not a valid alias. These of kind of aliases result in the future readers having to reference back to the table to find what that means. Either don't alias or if you have some meaningless prefix to the table (eg company name) alias to remove that
Just remember you're only writing it once. It'll be read 100s of times!
Or another favourite and one not everybody agrees with
If it's not readable it's wrong!
|
|
|
|
|
|
|
Quote: buy the world's ultimate board-game modification kit
I was so impressed I bought two!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Even that's overpriced. You don't need to write down your cheatinghouse rules at all to play with them. 
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing 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
|
|
|
|
|
Because I want game night to end in political debates with a couple of fights and at least one couple filing for divorce.
And that for a game that's already notorious for sparking fights[^] 
|
|
|
|
|
|
not good enough!
equal reward per identity for people with Dissociative Identity Disorder !
Message Signature
(Click to edit ->)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
