IMHO having this as a rule that keys in dictionaries are sorted alphabetically can be a valid rule. But this should be enforced in tooling, not "rules", and not through micromanagement. Much like using opinionated code formatters - like `prettier` you mention. It makes lives of everyone easier down the line.

Sometimes this comes from years of experience (mostly pain ;)). Some leaders, while coming from a good place - I want to help you, and others, avoid pain in the future - communicate it very badly - do it like that... because I say so!

> having this as a rule that keys in dictionaries are sorted alphabetically can be a valid rule

Ordering keys to prevent randomness is very helpful to spot changes when using "git diff", doing code reviews, comparing files side by side.

Often it helped me spotting bugs due to a missing or unwanted element.

I wish code linters had enabled by default with the ability to disable it with some simple syntax.

I had a look at prettier's github issues in the mean time and

> No, prettier tries not to change the semantics (specifically, the AST) of the program, and sorting imports/keys could break that guarantee. See here for more details and context, as well as links to similar/duplicate issues: #1684 (comment)

it makes sense not to make it a default.

https://github.com/prettier/prettier/issues/2460 https://github.com/prettier/prettier/issues/1684#issuecommen...

I think another option is to just let it go and you can "fix" it later if you want and have the chance. Just put it in a "cleanup" commit or something. Don't be passive agressive about it, make it a team practice. Sometimes people will change the style of your code, that's ok, it's not a slight against you.

However, if you get in a situation where people are changing styles back and forth then you need to talk it out. E.g. Alice inserts a blank line, Bob removes the blank line, Alice inserts the blank line again - time to talk about blank lines and code style.

In this case, if Alice sorts the dictionary keys and Bob couldn't care less, it seems both can have what they want by simply letting Alice sort the keys. And if it becomes a common thing instead of a one-off, maybe talk about it.

That makes it way easier for one person to find (who actually knows the names they chose for the keys) but just about impossible for everybody else.

Girly?

Yes, see https://headrush.typepad.com/creating_passionate_users/2006/... and https://signalvnoise.com/archives2/beautiful_code_testfirst....

I don't have good memories from the whole thing.

Thanks for posting the context for such a bizarre description. I can assure you that it's not worth continuing that train of thought.

However, if you want a positive, constructive frame the goal is self-documenting code. In that vein, here is a set of ideas I made a major contribution to amongst many other serious-minded software engineers.

http://wiki.c2.com/?SelfDocumentingCode

Haven’t read the articles, but wow, this idea needs a new name

Why? Does something being "girly" strike some kind of negative emotion? I don't think it is bad to associate organized and elegant code as feminine. You probably should read the article

> And there you have it. I think "girl code" is quite a compliment. Because caring about things like beauty makes us better programmers and engineers. We make better things. Things that aren't just functional, but easy to read, elegantly maintainable, easier--and more joyful--to use, and sometimes flat-out sexy.

Whether you see a trait as a positive or a negative does not mean it is useful to anyone to ascribe gendered terms to it.

A female software engineer who does not strive for beauty in code, is she less feminine? A male software engineer who strives for code beauty more feminine than the female one?

It is a useless argument to get into, when the actual way to describe the type of code would be a choice of "beautiful, sorted, structured, consistent" instead.

Gender, as such, has nothing to do with it.

Thanks, you've expressed this better than I could

Not at all, I'm just wary of reinforcing gender stereotypes.

Even in the conclusion quoted here, the author says "I think it's quite a compliment". As if when you first hear the term "girl code", you're supposed to think "ew", and the author is there to convince you otherwise.

Why not just call it neat or organised instead? Using a gendered term does nothing but appeal to stereotypes and solidify them.

It's a prejudice about the human doing the work. It's not complicated to understand what the problem is. You should judge the work on the intrinsic merits of the work, not the worker. Every human has the right to work and be evaluated on the work, independent of the nature of their birth.