> That is leaving the audience to cope with a design decision based on a > personal opinion. And yes. This is my personal opinion.
Its not only your opinion because i also agree with you. It has advantages but the disadvantages do seem to out way the advantages. **Non-uniformal type including** Lets say author A makes foo_bar. You include this and rewrite it to: fooBar. As you are typing, busy, busy, you rely on the intellisense code suggestions. Now you quickly write foo_bar because its the default. All of a sudden you have two different version of the same naming in your base code. So while constancy can be enforced by paying attention all the time, its not always the case. **Search** Sorry Araq but that is totally not true what you say. I can not think of a single editor that will allow a fuzzy logic search pattern ( unless you use regex ). Just right now, i had some variable "isPromotionModifed" giving me notifications errors ( yea, it has a typo, blame the developer that wrote it ;) ). PHPStorm -> CTRL+SHIFT+F -> Find all occurrences in code. Bingo ... If that same was: isPromotionModifed, is_Promotion_Modifed, is_PromotionModifed, is_promotion_modifed, ... There is no way i will search for all occurrences. Let alone potentially find them. **Searching in core code & modules** I just imported a nim module of mine with unit_Card in the module. I write unitCard in the main class. A simple search in VSCode simply shows: unitCard. It can not find the one in the module. No popular IDE that i know can handle nim/fuzzy searches like that. **Mixing** Like it was stated before, it opens up the door of several types getting mixed like GL_INT / GLint / ... * * * To me it looks more or less like a features that can be great for single personal development but a total disaster in a team. Only if a standard set of rules can be applied, then it might be more useful in a team. Allowing them to write a single style and have a more nicer import. My day job is literally (trying) to rewriting horrible amateur PHP code, that was written in East Europe. Its full of errors, non-standard variable naming structures, a utter and complete mess. My best tool for that is simple PHPSTORM / CTRL+SHIFT+F. Find all occurrences over all the files. You have the same variable over a dozen files at times. A mess. It takes time to figure it out. Now if i try to imagine if the same code was written in Nim, with different imports of the same variable names. I will not find all occurrences or will have a regex search that is so broad, that the results will include more variables then needed. Its not hard to imagine the result over time. To me it feels a bit like some PHP features. Sounds like a good idea in professional hands but quickly turns into a hated features on the long term because of the problems. The main advance is that you can try to structure the naming how you like. But it can never replace the names already written in the modules, bringing us back to the above points if there are problems, our your searching from memory ( based upon your structure ), etc etc. * * * Its not like there is a module import rule where we can say: _ need to be removed. first letter need to be upper_lower cased. Combined words like fooBar need to be split. Whatever... > Is a rule system existed, then its a different ballgame because you can > simply state that that all module imports needs to be converted to your > standard ( like a automated advanced code formatting ). That removes the need > for advanced searches & integrates perfectly with existing IDE's. Just some > food for thinking about. Because this is the only solution that i see that > solve the issue and still allows the ability to have freestyle naming ( for > those that want to use it ).
