I had occasion to be out on the back roads in Utah with a local. At every little hamlet the speed limit dropped 20 mph in two increments over about 50 yards. As was explained to me it was for revenue. Either you'd break one or the other speed limits, or you'd do a panic slowdown & get ticketed for "reckless driving"; either way a nice fine for the town coffers.
Realistically, how is this different from logging login attempts? If the device is configured to attach to the company network isn't it within the company's rights to know that a device is logged on at any given time even under GDPR? Or would it be the publication of that information - even internally - that would be the issue?
>If the device is configured to attach to the company network isn't it within the company's rights to know that a device is logged on at any given time even under GDPR? Or would it be the publication of that information - even internally - that would be the issue?
Logging anonymized MAC addresses is one thing, but converting the MAC addresses to employee names, revealing their location on premises that is shared with everyone in the organization without their consent is a completely different thing and is illegal under most EU privacy laws (at least in Austria and Germany).
Sure, in theory the company could already know when I come it at work from the logs of me swiping my access badge at the main security entrance door but any such logs are kept private and can only accessed by security and upper management if some act of theft or gross misconduct has occurred which warrants an investigation.
Sharing this information publicly with everyone in the org would be a privacy breach. If you want to know if I'm "at work" just look at my Slack/$CHAT_APP notification color.
He also said his statement "This is never about what runs fastest...". Kernel code needs to run fast and take advantage of shortcuts.
IME, the jobs most programmers are doing don't need to try to accomplish maximum speed or need to wring a few bytes out of RAM. Certainly we don't want to be wasteful, but long-term maintainability is more important, again IME, than absolute speed or minimising memory footprint by a few (k) bytes.
Back in the bad old days when I was writing programs to run on mainframes, yeah, we did need to fight for every byte. A $5 million machine back then had less RAM and less raw CPU power than a tablet does today. We don't live in that world now.
> He also said his statement "This is never about what runs fastest...".
This style has nothing to do with running fast, it has to do with lowering the cognitive load of the rest of the function. A branch means you have two states to keep in mind (the state where the branch is taken, and the state where the branch is not taken). Without early exit, you have to keep both states in mind until the end of the function just in case.
With guard clauses, you can discard on of the states (the one which matched the clause) entirely.
Computers can do that repeatedly and reliably with even (hundreds of) thousands of discarded states. People reading code and trying to understand what's actually in play at line umptyfratz of function iGottaGetThisFixedNow(), not so much.
In the end, I'm not disagreeing with early exits per se, just that over time they can make it more difficult to understand function because assumptions about state have to adjust as a maintainer goes through the code. Those assumptions may have been crystal-clear to the writer originally but how many times is the original writer the only maintainer?
