Programmers that think they're smart
-
:thumbsup::thumbsup::thumbsup: :laugh: :laugh: :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
return JsonConvert.SerializeObject(Process(JsonConvert.Deserialize(inputStream.ReadToEnd())));
Such a PITA to inspect the intermediate results when debugging a problem. Is it bad data in the input? Is it bad data being produced by
Process? Does the output JSON look like what the client is expecting? Wouldn't you want to do some validation before handing off toProcess? What about atry-catchif the deserialization fails? What about atry-catchifProcessfails? :sigh:Latest Article - Slack-Chatting with you rPi Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
when the proper way to do it is don't read the stream into a string, json.net can parse right from the stream with less allocations.
HttpClient client = new HttpClient();
using (Stream s = client.GetStreamAsync("http://www.test.com/large.json").Result)
using (StreamReader sr = new StreamReader(s))
using (JsonReader reader = new JsonTextReader(sr))
{
JsonSerializer serializer = new JsonSerializer();
// read the json from a stream
// json size doesn't matter because only a small piece is read at a time from the HTTP request
Person p = serializer.Deserialize(reader);
}from [Performance Tips](https://www.newtonsoft.com/json/help/html/Performance.htm)
"Time flies like an arrow. Fruit flies like a banana."
-
return JsonConvert.SerializeObject(Process(JsonConvert.Deserialize(inputStream.ReadToEnd())));
Such a PITA to inspect the intermediate results when debugging a problem. Is it bad data in the input? Is it bad data being produced by
Process? Does the output JSON look like what the client is expecting? Wouldn't you want to do some validation before handing off toProcess? What about atry-catchif the deserialization fails? What about atry-catchifProcessfails? :sigh:Latest Article - Slack-Chatting with you rPi Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Object oriented programming. makes it soo much easier to read......... I use pretty much only C (windows drivers). It is extraordinary how simple it is. How flat. What you see is the machine working, right in front of your eyes. NO hidden functionality, ticked away in some derived function, or constructor. And of course it has to be this way, the environment is so chaotic, that the code, the machine, has to be 100% perfect. And you can see that just by looking at it.
-
return JsonConvert.SerializeObject(Process(JsonConvert.Deserialize(inputStream.ReadToEnd())));
Such a PITA to inspect the intermediate results when debugging a problem. Is it bad data in the input? Is it bad data being produced by
Process? Does the output JSON look like what the client is expecting? Wouldn't you want to do some validation before handing off toProcess? What about atry-catchif the deserialization fails? What about atry-catchifProcessfails? :sigh:Latest Article - Slack-Chatting with you rPi Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
I have found that writing code that is easier to debug is an idea that contradicts some of the more modern suggested coding patterns. I am someone who likes to use LINQ and lambdas but admit that sometimes it doesn't make debugging particularly easy.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
return JsonConvert.SerializeObject(Process(JsonConvert.Deserialize(inputStream.ReadToEnd())));
Such a PITA to inspect the intermediate results when debugging a problem. Is it bad data in the input? Is it bad data being produced by
Process? Does the output JSON look like what the client is expecting? Wouldn't you want to do some validation before handing off toProcess? What about atry-catchif the deserialization fails? What about atry-catchifProcessfails? :sigh:Latest Article - Slack-Chatting with you rPi Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
As far as I know, the compiler treats that code the same as this:
{
string data = inputStream.ReadToEnd();
SomeClass myObj = JsonConvert.Deserialize(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 DEBUGstring data = inputStream.ReadToEnd(); SomeClass myObj = JsonConvert.Deserialize(data) var processed = Process(myObj); return JsonConvert.SerializeObject(processed);#else
return JsonConvert.SerializeObject(Process(JsonConvert.Deserialize(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 -
when the proper way to do it is don't read the stream into a string, json.net can parse right from the stream with less allocations.
HttpClient client = new HttpClient();
using (Stream s = client.GetStreamAsync("http://www.test.com/large.json").Result)
using (StreamReader sr = new StreamReader(s))
using (JsonReader reader = new JsonTextReader(sr))
{
JsonSerializer serializer = new JsonSerializer();
// read the json from a stream
// json size doesn't matter because only a small piece is read at a time from the HTTP request
Person p = serializer.Deserialize(reader);
}from [Performance Tips](https://www.newtonsoft.com/json/help/html/Performance.htm)
"Time flies like an arrow. Fruit flies like a banana."
I don't want to do either of those two things. So I rolled my own JSON iterator. JSON in, XML out. :D
-
As far as I know, the compiler treats that code the same as this:
{
string data = inputStream.ReadToEnd();
SomeClass myObj = JsonConvert.Deserialize(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 DEBUGstring data = inputStream.ReadToEnd(); SomeClass myObj = JsonConvert.Deserialize(data) var processed = Process(myObj); return JsonConvert.SerializeObject(processed);#else
return JsonConvert.SerializeObject(Process(JsonConvert.Deserialize(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, 2013That 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!
-
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
-
return JsonConvert.SerializeObject(Process(JsonConvert.Deserialize(inputStream.ReadToEnd())));
Such a PITA to inspect the intermediate results when debugging a problem. Is it bad data in the input? Is it bad data being produced by
Process? Does the output JSON look like what the client is expecting? Wouldn't you want to do some validation before handing off toProcess? What about atry-catchif the deserialization fails? What about atry-catchifProcessfails? :sigh:Latest Article - Slack-Chatting with you rPi Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
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,
-
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!
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 -
return JsonConvert.SerializeObject(Process(JsonConvert.Deserialize(inputStream.ReadToEnd())));
Such a PITA to inspect the intermediate results when debugging a problem. Is it bad data in the input? Is it bad data being produced by
Process? Does the output JSON look like what the client is expecting? Wouldn't you want to do some validation before handing off toProcess? What about atry-catchif the deserialization fails? What about atry-catchifProcessfails? :sigh:Latest Article - Slack-Chatting with you rPi Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
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.
-
As far as I know, the compiler treats that code the same as this:
{
string data = inputStream.ReadToEnd();
SomeClass myObj = JsonConvert.Deserialize(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 DEBUGstring data = inputStream.ReadToEnd(); SomeClass myObj = JsonConvert.Deserialize(data) var processed = Process(myObj); return JsonConvert.SerializeObject(processed);#else
return JsonConvert.SerializeObject(Process(JsonConvert.Deserialize(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, 2013Yeah 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
-
I have found that writing code that is easier to debug is an idea that contradicts some of the more modern suggested coding patterns. I am someone who likes to use LINQ and lambdas but admit that sometimes it doesn't make debugging particularly easy.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
return JsonConvert.SerializeObject(Process(JsonConvert.Deserialize(inputStream.ReadToEnd())));
Such a PITA to inspect the intermediate results when debugging a problem. Is it bad data in the input? Is it bad data being produced by
Process? Does the output JSON look like what the client is expecting? Wouldn't you want to do some validation before handing off toProcess? What about atry-catchif the deserialization fails? What about atry-catchifProcessfails? :sigh:Latest Article - Slack-Chatting with you rPi Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
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.
-
return JsonConvert.SerializeObject(Process(JsonConvert.Deserialize(inputStream.ReadToEnd())));
Such a PITA to inspect the intermediate results when debugging a problem. Is it bad data in the input? Is it bad data being produced by
Process? Does the output JSON look like what the client is expecting? Wouldn't you want to do some validation before handing off toProcess? What about atry-catchif the deserialization fails? What about atry-catchifProcessfails? :sigh:Latest Article - Slack-Chatting with you rPi Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
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.
-
return JsonConvert.SerializeObject(Process(JsonConvert.Deserialize(inputStream.ReadToEnd())));
Such a PITA to inspect the intermediate results when debugging a problem. Is it bad data in the input? Is it bad data being produced by
Process? Does the output JSON look like what the client is expecting? Wouldn't you want to do some validation before handing off toProcess? What about atry-catchif the deserialization fails? What about atry-catchifProcessfails? :sigh:Latest Article - Slack-Chatting with you rPi Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
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.
-
GuyThiebaut wrote:
code that is easier to debug is an idea that contradicts some of the more modern suggested coding patterns.
Or it's just because so many "developers" do not learn or understand debugging. When things don't work they just open a QA.
When the guy who wrote the code has to spend an half an hour figuring out what the code actually does, is it a lack of debugging skill on the other people's part?
-
When the guy who wrote the code has to spend an half an hour figuring out what the code actually does, is it a lack of debugging skill on the other people's part?
-
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.
-
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.
