hexate posted:

A perennial favorite of mine - pure, undistilled fuckery. This if continues into a business logic pyramid of doom...

code:

	String property = getString(PROPERTY_NAME);
	//if property is allowed.
	if(property.equals("DISALLOW")
	{

Is the comment wrong? Is the conditional wrong? Or is this some sick joke where "DISALLOW" means allowed?

Every customer has their own opinion. This gem was written a decade ago, and both the product owner and developer have long since moved on

hexate posted:

A perennial favorite of mine - pure, undistilled fuckery. This if continues into a business logic pyramid of doom...

code:

	String property = getString(PROPERTY_NAME);
	//if property is allowed.
	if(property.equals("DISALLOW")
	{

Is the comment wrong? Is the conditional wrong? Or is this some sick joke where "DISALLOW" means allowed?

Every customer has their own opinion. This gem was written a decade ago, and both the product owner and developer have long since moved on

Ola posted:

Maybe an example of code getting updated but not comments.

Dylan16807 posted:

I don't know how I can be clearer than "You don't change the CAN communication. It already works."

iospace posted:

We get it dude, you've worked on it.

Now are you capable of responding without being a jackass? Looks like that answer is no.

JawnV6 posted:

Why is it y'all think I'm being a jackass?

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.

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.

Actually I haven't in depth, I'm just miles closer than some DBA who's never glanced at a schematic or bothered to expand COGS. He's not even pretending to understand the domain or even the solution he's proposing, sticking with a garbage answer that's wholly inappropriate.

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?

JawnV6 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?

do you let yokels from unaffiliated disciplines give you notes on the digital systems you design? why or why not?

JawnV6 posted:

Does CAN require an in-band ACK/NACK differentiation?

JawnV6 posted:

if you're not trying to duck the questions, wanna take a whack at these unanswered gems


i seriously boiled it down as much as i could and put the direct question right to you, and i can't find a simple yes/no answer to these basic questions

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

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?

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.

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.

JawnV6 posted:

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.
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.

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?

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?

Opferwurst posted:

Saw this gem today

code:

if(someList.Count <= 0)

Opferwurst posted:

Saw this gem today

code:

if(someList.Count <= 0)

Peewi posted:

You know, in case it's very empty.

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.
I would just do (or the inverse):

code:

if someList?.Any()

Because it reads better. There is a perf hit but lmao at caring about this level of optimization.

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.

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!

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.

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!

Xarn posted:

If the size is < 0, you should hard crash right now.

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 "<=".

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?

Magissima posted:

The real horror is capitalized method names.

taqueso posted:

TBH CANbus is a poor choice for anything that needs security.

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.

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.