coloredgrayscale @ coloredgrayscale @programming.dev

Posts

0

Comments

93

Joined

2 yr. ago

The 2nd is the style guide used in C#, and therefore what you've encountered in unity.

There's more than just hardware and power cost to servers.

Primarily cost of employees taking care of the servers.

Maybe also bias by the number / experience of people using it.

1st semester students getting shocked by public static void main(String args) and meming it on the internet.

Go on the other hand likely isn't a common choice / option for a first language.

Assembly would be lower. You have more complex / direct instructions in assembly. Brain fuck is pretty much just a pure turing machine, and has 8 instructions.

X86 has ~ 1000 + variants. Even ARM with a smaller instruction set has 232 instructions.

In brain fuck to set a number you'd have to count up (or down - underflow) to that number. In assembly you just set it.

Somewhere I've read that current assembly code with Makros should be similar to writing C.

We ignore them.

Usually a translation system might return the key value if the translation is missing. By translating with "untranslated" as a default you'd get just that text filled as fallback.

Unless you reinvent the wheel for lookup and can just ignore your magic value, or put an if on every value lookup.

Might be a risk there.

If they need it often it makes some sense, if it also perform some checks, if the list if empty or None/null.

What if I pass an empty list, or NoneType?

If someone changes the code and forgets to modify the comment, the reader might favor one or another at random.

Hence why you should comment why, not how/what.

// slow down traffic before crossing busy main road

Now you can change the stop sign to a yield without touching the comment. Or judge that the comment can be removed if it's clear the main road does no longer exist.

They meant self obfuscating.

Can someone transcribe this text please?

Adding the fourth, ultimate escape to it.

Sounds like a good use of comments. Explain why, not how. (that should be readable from the code for the most part. Unless you're having function calls like xmmmuldp (simd) )

"too many comments".

you could document the steps required in text and add Screenshots.

but then why would they ask candidates to write functions like binary tree traversal from scratch during interviews? /s

Seems fitting for points 1 and 2 XD

What did you use as tools, or was it a masterlock?

They should have used Quarkus /s

Exactly. Use the tools you have the way they fit you best. If it aids your work flow learn the CLI commands you use the most. If it's something obscure or rarely used, use the gui.

Another not mentioned benefit of becoming comfortable with using the cli is that you then can more easily script stuff.