hexate posted:A perennial favorite of mine - pure, undistilled fuckery. This if continues into a business logic pyramid of doom... What really gets me here is that I expect 'getString' to give me a string representation of the property value or property name. Definitely would not expect it to give me a string expressing whether or not it's allowed in whatever context.
|
|
# ? May 13, 2019 19:59 |
|
|
# ? Jun 21, 2024 14:18 |
|
Even better, there are only two expected states for the property anyway, and yet, its stored AND interpreted as a string...
|
# ? May 13, 2019 20:20 |
|
Yet another example of "stringly typed" code
|
# ? May 13, 2019 20:28 |
|
hexate posted:A perennial favorite of mine - pure, undistilled fuckery. This if continues into a business logic pyramid of doom... I only read comments if they're good. If they're stupid (like that one), code wins. I've worked on codebases where primary developers were Japanese speakers, and the comments were in Japanese, and frankly I didn't miss being able to read comments at all.
|
# ? May 13, 2019 20:53 |
|
Maybe an example of code getting updated but not comments.
|
# ? May 13, 2019 21:28 |
|
Ola posted:Maybe an example of code getting updated but not comments. I had hoped so too, but both lines were added in the same commit!
|
# ? May 13, 2019 21:32 |
|
Dylan16807 posted:I don't know how I can be clearer than "You don't change the CAN communication. It already works." I gave an example of where "don't change the $protocol communication" is literally impossible to do, there are in-band situations that require agent participation to signal state. I'm asking if CAN is similar in this respect, in which case "don't change the CAN communication it already Works" is electrically impossible to achieve. But since you're too dumb to clock the question you retreat to the dumb bullshit you've been peddling, acting as if this distance from the problem is a virtue instead of precluding any such solution. iospace posted:We get it dude, you've worked on it. Why is it y'all think I'm being a jackass? I'm boiling this down to trivial yes/no questions that an honest read of Wikipedia would answer conclusively. You'd genuinely prefer the ignorant poster shooting from the hip here in the *checks notes* Coding Horror thread?
|
# ? May 13, 2019 21:34 |
|
JawnV6 posted:Why is it y'all think I'm being a jackass? Your posts
|
# ? May 13, 2019 22:23 |
|
JawnV6 posted:You're being nonsensical. I'd like to understand what you're proposing, but your vast ignorance is precluding a good faith discussion. Does CAN require an in-band ACK/NACK differentiation? This question is central to answering if we can add your data diode "outside CAN" or not, and your indifference to the details yet again takes front and center as you decline to even appreciate the question's importance. Pretend we took the existing entertainment unit and disconnected all the buttons and plugs. That is what I mean by "don't change it", in the most godawful prototype form. If you think I'm describing something that's electrically impossible, then there is definitely a misunderstanding. To continue with the world's worst prototype, while removing the buttons we set it to a debug display that has all the CAN info it needs. Then we build a whole new entertainment unit on top, with a camera to get that info. Screen to camera is the data diode. The next step is replacing screen->camera with a single wire. Then we remove 90% of the parts in the inner unit because they're not doing anything any more. Now we have a single compact entertainment unit, where one sub-circuit does things on the network autonomously, and it's impossible for button presses to affect it. I like the idea of a database analogy. Because even someone who has never touched a database can say "Hey, this query is what we need. We could make a cron job that does that query and puts the results in a file. That way no matter how badly our application gets compromised, it can't change the database query." It's not necessarily a good solution, but it would do the job. Dylan16807 fucked around with this message at 23:15 on May 13, 2019 |
# ? May 13, 2019 23:00 |
|
if you're not trying to duck the questions, wanna take a whack at these unanswered gemsJawnV6 posted:do the CAN systems you've worked with NACK for any reason other than a CRC mismatch? can that information be shuffled back and forth across the data diode you've selected for this application? what would the failure mode be if the CAN node didn't respect this area of the protocol? JawnV6 posted:Does CAN require an in-band ACK/NACK differentiation? i'm not engaging with yet another whack at handwaving furiously and verbosely enough to hide the fact you don't know this fundamental question
|
# ? May 14, 2019 01:09 |
|
JawnV6 posted:if you're not trying to duck the questions, wanna take a whack at these unanswered gems Would you please explain how ripping out all the buttons and user-accessible ports from the entertainment system wouldn't make it hack-proof, and a garbage but functional data diode? I'm not suggesting that as a finished solution. It's an example to show that "electrically impossible" is you talking past me, and refuting an imaginary argument. It doesn't matter that I don't know much about CAN. I made an argument that works for any network.
|
# ? May 14, 2019 01:55 |
|
The right answer is to not try and put a data diode on the can bus, instead you give the entertainment unit a separate component for talking to the bus and put your data diode in between that and the entertainment unit proper. (Hell, you might have that separation already, presuming you're not piping your 100V transients directly into your entertainment unit processor). (You might not even need an explicit diode component, if the interface for talking between the two parts only allows for one-way communication). Which I think is what Dylan is trying to get at, but it's not really obvious from the initial "stick a data diode on it". This scheme does fall apart in other ways once you start wanting the entertainment unit to be able to send some types of messages but not others.
|
# ? May 14, 2019 02:13 |
|
"Since we're using that name like that for a property that exists but we want to deserialize into a different property, we need to flag this one to be ignored" I say last week. Today, a request to code review. code:
My colleague smirks. "It works." he says. "Sure but does it work...on accident or by design?" He rolls his eyes slightly. "I didn't make this up, it's from an answer on StackOverflow." His tone suggests this proves something. He pulls up the tab with the SO answer and scrolls through the various code snippets. Almost immediately, my eyes see it: code:
"Why are we looking at Java code?" I ask. He pauses. Looks up. Looks away. Looks at the screen. Looks away. Looks at me. "Well, it's probably one library that uses common code." "Between Java and C#?" Looks up. Looks away. Looks up. Looks away. "I mean. It could."
|
# ? May 14, 2019 07:27 |
|
LGTM, ship it.
|
# ? May 14, 2019 07:38 |
|
Dylan16807 posted:Reasons for NACK: Doesn't matter, I'll assume the worst case that it can, but the existing code already handles that. Can information be shuffled back and forth: Yes, otherwise how would the system already work? What would the failure mode be: The same as if the existing system failed, but now the user can't be the cause. Do I let yokels offer advice on what I design: yes. Dylan16807 posted:Can it require in-band differentiation: Doesn't matter, I'll assume the worst case that it can, but the existing code already handles that. Dylan16807 posted:Would you please explain how ripping out all the buttons and user-accessible ports from the entertainment system wouldn't make it hack-proof, and a garbage but functional data diode? do you think people are hacking cars by TAS'ing konami codes into the head unit buttons? is that the only possible threat model you've considered? christ this is a farce Dylan16807 posted:I'm not suggesting that as a finished solution. It's an example to show that "electrically impossible" is you talking past me, and refuting an imaginary argument. It doesn't matter that I don't know much about CAN. I made an argument that works for any network. in network terms, if i send out a packet and don't hear a response, is a reasonable solution to re-send the packet? if i send out "volume up" and don't hear back (because you lopped off the entertainment unit) what happens if the button tries to re-send? could it possibly block other more critical communications from occurring? Jabor posted:This scheme does fall apart in other ways once you start wanting the entertainment unit to be able to send some types of messages but not others.
|
# ? May 14, 2019 17:42 |
|
Obviously what he is saying is that the piece of hardware in a car radio in charge of reading data from the CAN and sending ACK/NACK messages should be segregated from the piece of hardware in charge of running the buttons and radio antenna. You are free to design the internal communication between these two components of your radio in any way since it does not affect the external interface that the rest of the vehicle sees. The CAN-talk-to-er chip unavoidably has write access if it is connected to the network, but the radio proper does not need to (and should not) have write access to its CAN-talk-to-er.
|
# ? May 14, 2019 18:37 |
|
Saw this gem todaycode:
|
# ? May 14, 2019 21:18 |
|
RPATDO_LAMD posted:Obviously what he is saying is that the piece of hardware in a car radio in charge of reading data from the CAN and sending ACK/NACK messages should be segregated from the piece of hardware in charge of running the buttons and radio antenna. You are free to design the internal communication between these two components of your radio in any way since it does not affect the external interface that the rest of the vehicle sees. JawnV6 posted:the entire loving point is you don't trust the "existing code" and just saying "existing code already handled!" means you're giving that write access to the agent we're considering a threat? In loose terms, this is a data diode "attached to" the CAN bus via the agent. In more precise terms you have a sequence of CAN<->agent->diode->rest of the entertainment unit. JawnV6 posted:radios can allow software access without a user-accessible button JawnV6 posted:do you think people are hacking cars by TAS'ing konami codes into the head unit buttons? is that the only possible threat model you've considered? christ this is a farce JawnV6 posted:in network terms, if i send out a packet and don't hear a response, is a reasonable solution to re-send the packet? if i send out "volume up" and don't hear back (because you lopped off the entertainment unit) what happens if the button tries to re-send? could it possibly block other more critical communications from occurring? Dylan16807 fucked around with this message at 21:41 on May 14, 2019 |
# ? May 14, 2019 21:36 |
|
Opferwurst posted:Saw this gem today You know, in case it's very empty.
|
# ? May 15, 2019 00:24 |
|
Opferwurst posted:Saw this gem today Other than the less than being useless, what are the other problems with this code? What does Count return? int? uint? size_t?
|
# ? May 15, 2019 00:37 |
|
32 bit signed int, but it won't be less than zero. I'd argue it's really not a coding "horror", just has some redundancy. I would be generous and just say the author was used to being explicit elsewhere and just did it here without really thinking. someList could also be null so it can throw a null exception when checking count if it hasn't been checked yet. I would just do (or the inverse): code:
|
# ? May 15, 2019 04:38 |
|
Peewi posted:You know, in case it's very empty. A biologist, a physicist and a mathematician sit in a cafe one morning and observe the office building over the road. They see two people arrive, unlock the doors and go inside. A few minutes later, to their surprise they see four people leave the building. "Ah", says the biologist, "they have reproduced". The physicist shrugs. "There's no problem here", he says, "the observations weren't accurate enough". The mathematician remarks, "If two more people go into the building, it will be empty again."
|
# ? May 15, 2019 13:42 |
|
Xik posted:32 bit signed int, but it won't be less than zero. I'd argue it's really not a coding "horror", just has some redundancy. I would be generous and just say the author was used to being explicit elsewhere and just did it here without really thinking. someList could also be null so it can throw a null exception when checking count if it hasn't been checked yet. Personally I believe that Empty() would read better than Any, but that's neither here or there. Checking for "Count <= 0", especially when said Count returns a signed value just screams of defensive programming. You never know when the value could potentially overflow, when a bug in that list implementation may return -1, when radiation from the sun will flip a bit. Since I have a hard time believing that "== 0" is more efficient than "<= 0" I would almost always prefer the "<= 0" if something like "Empty" is not available.
|
# ? May 15, 2019 13:52 |
I don't like Empty() as a method name for checking for collection being empty. It reads just as much as a verb, the boolean method should be named IsEmpty().
|
|
# ? May 15, 2019 14:02 |
|
If something completely and utterly unexpected by the programmer has happened, your code should crash loudly and messily rather than trying to carry on as best it can. If your data has been corrupted by a random bit-flip, carrying on as though nothing has happened is likely to be the worst possible option!
|
# ? May 15, 2019 14:02 |
|
Jabor posted:If something completely and utterly unexpected by the programmer has happened, your code should crash loudly and messily rather than trying to carry on as best it can. The real fun stuff is when your code gets corrupted by a random bit-flip.
|
# ? May 15, 2019 14:17 |
|
Jabor posted:If something completely and utterly unexpected by the programmer has happened, your code should crash loudly and messily rather than trying to carry on as best it can. In this particular case one can argue: I don't really give a drat about the "why's", all that i care about is that i do not have zero (or less) elements in the list. Adding an assert or another check for the completely off the wall return values is of course another possibility. Now, if benchmarking would show that <= is slower than ==, then sure, by all means ban the use of "<=".
|
# ? May 15, 2019 14:32 |
|
If the size is < 0, you should hard crash right now.
|
# ? May 15, 2019 14:36 |
|
Xarn posted:If the size is < 0, you should hard crash right now. For some applications this is certainly the only correct move. For most people/domains/applications out there an acceptable answer is to go on and just ignoring crap like that (especially when that list will probably get garbage collected soon) which is most likely caused by a weird library bug. Of course, YMMV. Edit: This is a silly argument to have. If I would see this code in a project that I'm working on, I'll probably just shrug it off. It's a "meh" at most. But I can see why it can rub some people off in the wrong way. Volguus fucked around with this message at 14:50 on May 15, 2019 |
# ? May 15, 2019 14:45 |
|
Volguus posted:In this particular case one can argue: I don't really give a drat about the "why's", all that i care about is that i do not have zero (or less) elements in the list. Adding an assert or another check for the completely off the wall return values is of course another possibility. Now, if benchmarking would show that <= is slower than ==, then sure, by all means ban the use of "<=". What if the programmer wants to check if the list is empty, and count < 0 doesn't mean the list is empty because the integer overflowed? As for the code in question, my first guess was that the programmer had tried something like count <= 1 while troubleshooting a fencepost error, and eventually settled on 0 without changing the operator.
|
# ? May 15, 2019 14:45 |
|
Volguus posted:Other than the less than being useless, what are the other problems with this code? What does Count return? int? uint? size_t? code:
The Any() extension method exists for this purpose though, unless you're cursed to work on something so old that you can't use linq. Not really a horror, but it invites the opportunity to make a mistake by accidentally writing list.Count < 0. dougdrums fucked around with this message at 15:21 on May 15, 2019 |
# ? May 15, 2019 15:15 |
|
I hadn't seen anyone use .Any() to check for an empty list until I got to my current job and I'm still trying to get used to it Makes perfect sense, it's just not the idiom I'm used to.
|
# ? May 15, 2019 15:26 |
|
The real horror is capitalized method names.
|
# ? May 15, 2019 15:43 |
|
TBH CANbus is a poor choice for anything that needs security.
|
# ? May 15, 2019 15:53 |
|
Depending on language/implementation, In some cases calling a count() will traverse the list to get the count - if you're trying to see if an enum/list is non-empty, doing an equivalent of 'list != []' might be quicker.
|
# ? May 15, 2019 15:56 |
|
Magissima posted:The real horror is capitalized method names. It'd be really hosed up if if I incorrectly assumed that this was C# and it happens to be Java or C++ instead.
|
# ? May 15, 2019 15:58 |
|
taqueso posted:TBH CANbus is a poor choice for anything that needs security. All's I know is networks is how you get Cylons and I don't want no Cylons in mah car
|
# ? May 15, 2019 16:08 |
|
dougdrums posted:It'd be really hosed up if if I incorrectly assumed that this was C# and it happens to be Java or C++ instead. Writing Powershell has made me horribly inconsistent about case sensitivity in my code.
|
# ? May 15, 2019 18:44 |
|
Volguus posted:Personally I believe that Empty() would read better than Any, but that's neither here or there. Checking for "Count <= 0", especially when said Count returns a signed value just screams of defensive programming. You never know when the value could potentially overflow, when a bug in that list implementation may return -1, when radiation from the sun will flip a bit. Since I have a hard time believing that "== 0" is more efficient than "<= 0" I would almost always prefer the "<= 0" if something like "Empty" is not available. I asked about it and apparently it's what happens when you use some ReSharper auto refactoring functionality. It inverts a ">0" statement, but isn't smart enough to know that arrays can't have a negative size. Also, gotta agree that if the fabric of space and time broke down and System.Collections started producing negative sized arrays I would want my program to drop everything and tell me ASAP.
|
# ? May 15, 2019 20:03 |
|
|
# ? Jun 21, 2024 14:18 |
|
Maybe that's what will happen when the Earth's magnetic field flips polarity.
|
# ? May 15, 2019 20:13 |