|
|
Richard, I'm guessing you never had to deal with code that was complex enough that, some 3 months after writing it, the author had to figure out what he wrote?
If so, count your blessings.
|
|
|
|
|
BryanFazekas wrote: the author
Are you talking about yourself? And I am not sure how this relates to my original comment.
|
|
|
|
|
As far as I know, the compiler treats that code the same as this:
{
string data = inputStream.ReadToEnd();
SomeClass myObj = JsonConvert.Deserialize<SomeClass>(data)
var processed = Process(myObj);
return JsonConvert.SerializeObject(processed);
}
even if it didn't precisely, at least you can debug it one step at a time.
You could also do this if you had the itch (but it is fairly pointless:
{
#if DEBUG
string data = inputStream.ReadToEnd();
SomeClass myObj = JsonConvert.Deserialize<SomeClass>(data)
var processed = Process(myObj);
return JsonConvert.SerializeObject(processed);
#else
return JsonConvert.SerializeObject(Process(JsonConvert.Deserialize<SomeClass>(inputStream.ReadToEnd())));
#endif
}
".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
|
|
|
|
|
That would actually annoy me: the code getting tested and debugged isn't the same code as the release version, and is likely to get "out of step".
So it works in dev, and fails in prod. Nasty, to my mind.
I'd rather go with the former version and rely on the optimiser to remove the intermediate variables in prod.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I agree - the Debug directive is a really bad idea in my opinion as you now have two sets of code to maintain whenever you make a change.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
That was an "in the interest of completeness" thing.
".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
|
|
|
|
|
Yeah I'm with OG the former is definitely the way to go, then you're sure they are the same in both environments.
Got my site back up after my time in the woods!
JaxCoder.com
|
|
|
|
|
Thank you for this comment… Recently I took over some relatively big
Java/Eclipse/Tomcat projects and I see such things all over the place …
I even have no time to change this but it should be changed, of course 
It's the mindset indeed of such "devs" that is totally wrong …
BR,
|
|
|
|
|
I hate code like that. I hate it more when I submit code for a code review and I'm told to do things like that. I quite like code like;
Product p = GetProduct(params);
return p;
I know that GetProduct returns a Product class and the code lets me debug to see what "p" is. Invariably someone who "knows better" will tell me to use "var" or more likely just "return GetProduct". The reason it annoys me so is that when it comes down to compiled code it makes no difference. Optimisers render the output the same.
I remember in one job the tech lead had a hard-on for defining constants in their own classes (nothing wrong with that) but declaring them as static strings. I said we should use constants instead, I then began to explain "Because the compiler...." and he cut me off there saying "I don't care what the compiler does, we shouldn't change our code due to the compiler." Ok....strings it is then.
|
|
|
|
|
Frankly, I've been doing similar stuff myself quite frequently albeit after verifying that all the building blocks work.
A stack trace of the exception being thrown usually helps debugging when something truly unexpected happens, although I wouldn't consider Deserialie(UserProvidedData) an overly valid use case for such one-liners.
|
|
|
|
|
I have found myself a few times in C# and JavaScript when debugging that I needed to add a return line just to break point inside some anon function. It's a bit nice once in line breaking was added, but I do like the push to split up code for more readable instead of compact lines.
|
|
|
|
|
Web developers working on a 80 char terminal, trying to be "efficient" and clever:
"Less lines means it's faster, right?" - every noob web developer
"Who cares about indentation, we save 2 lines here this way!" - Apple before the SSL fiasco.
|
|
|
|
|
the y2k bug come to my mind. on a 8bit computer one byte per date is a huge space optimization, but i don't believe that mainframe COBOL programmers had to be that careful.
also, i remember reading about an "optimization" of the old day ms-dos assembly programmers using the inability of i8086 to address more than 1MB so they wouldn't mind generating segment:offset addresses that past the megabyte barrier, because it will roll over and map into the address space of the zeroth+ segment. this of course caused latter compatibility issues.
there was a similar man made "optimization" problem on the first mc68000 Amiga's, but i don't recall enough info to check what was the trick there.
|
|
|
|
|
Quote: hey wouldn't mind generating segment:offset addresses that past the megabyte barrier, because it will roll over and map into the address space of the zeroth+ segment
Absolutely disgusting, this is the recipe CREATE legacy sh*t right from the start.
I can't even imagine the hacks Microsoft must have had to do keep old Win32 apps working in a modern OS.
|
|
|
|
|
Some IDE's have options to remove local variables. Don't ask me why!
I like them for debug STOP locations as the poster prefers.
I also like them for readability and documentation.
Boolean summaryDescription = (super nasty Boolean expression with 4-8 components);
if (summaryDescription) {
handleIt();
}
An ex-team member used to have their IDE preference to collapse these out of existence.
I hated looking at my code after they had performed some minor tweak on my code along with a "reformat".
|
|
|
|
|
If you can't explain something to a five year old you don't understand it yourself. (Einstein, I think).
Same goes for writing clear code.
|
|
|
|
|
Looks like something that older Unix C programmers would write. Easy to code, difficult to read.
|
|
|
|
|
They don't get any better ...
Presenting: Smarter Socks[^]
Yes! That's right: you can ask your socks when you last washed them, and if they are "still black". And all this for just £16 per pair!
I have no idea how I have coped so long without this.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
The app is only available in the apple app store.
I wonder why.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
on that they suggest to download the app before getting the socks as [paraphrased from their own words] later you may not bother to download it.
really, yes, sure, you bet ya I'm gonna do that right now ...
I really hope it keeps reminding me to order the socks, and whatever else you have in store - with regular updates (the app and the inventory).
Mark_Wallace wrote: The app is only available in the apple app store.
the goo is in the google play-store?
Message Signature
(Click to edit ->)
|
|
|
|
|
|
Imagine if that got hacked?
|
|
|
|
|
Yeah that was my initial thought also!
Got my site back up after my time in the woods!
JaxCoder.com
|
|
|
|
|
This product is just silliness. I refuse to believe this is a real product for sale.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
