A while back, I ranted about emojis in code.

My nightmares are becoming reality.

Behold, production code:

Awesome API feedback : 👍👎🎉⛔⁉🍕

I found more.

For the love of god, why?!?

Well that is some next level shit. I wonder if different encodings would cause errors 🤨

@horus you cannot be serious ? Yes some will be readable. But 🤷‍♀️ what is the meaning of this ? is it 'something went wrong' or "I don't know".

I would just return an error code and a reason what that error is.

Any system that provides accurate and specific feedback is okay by me. When I see 'Oops, something went wrong!!!' I think 'Yes: you got hired as a programmer'.

The only thing that sucks about emojis is that you can't type them properly.

If you could, this would be way more normal for everyone. Because let's be serious: "oops something went wrong!!" And "shrug" is the exact same fucking thing.

@nitwhiz Well any IDE could easily add it with an extension that works the same way mobile chat apps do, Discord for example.

Start with idk ':' and write what you want, 'success' and it shows fitting possibilities just like normal code completion~

@nitwhiz https://github.com/atom/... for example

No worries, I know for a fact we have in our golang backend right now:

if (message === "👋") {

// do some shit

}

probably should add some more like

if (stuff === "🤡")

to make it even better

@fullstackclown Yeah, making logic dependent on the value of error message strings is just programming greatness.

My 2 cents as a Devrant rookie, that it's not that bad of an idea if executed properly.

🄾🄿🅃🄸🄼🄸🅉🄰🅃🄸🄾🄽

1. The errors mappings should be centralized in a common package and mapped with enums ex typescript, or as a value in an object, so in code, you will use the ErrorCodes.SOMETHING_WENT_WRONG.

2. Both server/client should be using the same lib.

3. Emoji's are 4 bytes, and for non-performant apps are a good way to replace, your typically longer error codes like ERR_SOMETHING_WENT_WRONG

enum ErrorCodes {

SOMETHING_WENT_WRONG: '🤷‍♂️',

...,

}

For really performance-draining apps, for interservice comm, a 2-byte notation will result in 65536 possible commands to map to, which is plenty.

const ErrorCodes = {

SOMETHING_WENT_WRONG: 0x00

}

4. With this said, for inter-process/service comm always use tracing the errors origin or provide more information about the error along the way.

I kind of hate they added emoticons to Unicode

@nitwhiz shrug can mean other things as well

Emojis look different on every platform. They sometimes even depict different things, also. For example the same emoji might look like a single brick on one platform but it might look like a brick wall on another platform or app. It’s ambiguous and it’s hard to convey a meaning. It’s marginally better than some random number.

And then you also have different variants like skin color and gender and what not. And some emojis are not available on some platforms.

It’s just a bad idea.

@Lensflare exactly, try opening a js file with emojis in notepad++...

For the others here,

🤷‍♀️ = 🤷‍♂️️‍♀️ in notepad++

@Lensflare also, emoji are usually so small that you can't really see what they are unless you copy paste them to a search engine

@Grumm so I'm to understand the bitmaps aren't even integrated at the os level in b and w ?

It's all up to the app or dm ?

There's more than one emoji that expresses something good. It's so... Uncertain. And inconvenient, as they aren't available on a keyboard and require to be copy-pasted. Try writing a hello world app by copy-pasting every char. Fun? Not really.

@horus

@AvatarOfKaine like @ElectroArchiver mentionned it. It all depends how to IDE translate the icons into a visual image.

Maybe on mac, they are shown differently. It may not affect the code (the unicode is hopefully the same)

In any case, it is not a reliable way of giving feedback

@Grumm Emojis, like any other unicode symbol are stylized by fonts, their code point is the same.

I think it's not that bad. We need more diversity and less snobbery.

@spongegeoff yeah that's where 👶 comes in. Demeaning toddler reaction.
It's fine to give something funny/custom back as long as a normal error is provided

oh wait

the code says “REACT_APP_API_DOMAIN”

😂

AND YOU EXPECT not to see emojis? they're using react!

in a company-wide _fun_project, one variable is named 🍆

👀

@jonas-w why is your score text +4833 so misaligned in that screenshot? 😄

@Lensflare devrant android app at its best, every score is misaligned

@jonas-w lol shit. My apologies.

@Lensflare thanks now i can't unsee it again, i forgot about it

Horrible for many reasons, I'll respond to some arguments in the comments.

Readability:

You can read an emoji by associating it with any of several words, or situations where it would be appropriate. You can read a word by reading it.

Alternatively, you can use a table to resolve it, but then you might as well have used a four letter symbol, or an integer, which can be typed on any keyboard, transmitted in speech, and searched manually in logarythmic time.

Diversity:

Emoji are fundamentally inaccessible and americentric because they rely on small details which are hard to see, and cultural context. Even the English language is less americentric than emoji, because it can be learned and understood on abstract terms without spending years socializing specifically with people of a particular culture. Inclusivity starts with simplicity and clarity.

Text can be unclear too:

And your favourite language can be written in an obfuscated manner, doesn't justify using Brainfuck.

Time to propose a new HTTP RFC: HTTP Status Emojis.

404=🗺️
500=😩
418=🫖
402=💸

Not using async/await, disgusting

@alexbrooklyn Also infallible happy path but the error handler isn't passed to the second argument of then. Catch blocks should only apply to the code you explicitly want to handle.

@spongegeoff to be fair sometimes too many things may go wrong and a programmer cannot predict and prepare the code for any of these. Usually I get around of this problem by trying to catch any issue I can to provide good feedback to user but if I have even a glimpse of doubt which I might have left something behind I prepare a catch-all which catches any unmanaged error, returns a generic message to the user while it sends all the information it can to my company’s logging/observability system so I can improve error feedback as fast as possible.