8 ms·
Do you have a moment to talk about our lord and saviour kebab-case?
by yakubin 4y ago
Do you have a moment to talk about our lord and saviour kebab-case?
- Waterluvian 4y agoonlyifwehavetimetotalkaboutflatcase
- aloukissas 4y agoALLCAPSCASEPLSFIX
- TylerE 4y agoThErEArRWOrSeOpTiOnSCaSe
- Zamicol 4y agoWe've dubbed this "ridicule" case. Upper case is majuscule. Lower case is miniscule. Mixed case is ridicule. https://en.wikipedia.org/wiki/Letter_case#Terminology https://en.wikipedia.org/wiki/Letter_case#Terminology
- downvotetruth 4y agoWoXCvSZ: randomly only capitalizing C,O,S,V,W,X,Z
- tmtvl 4y agoThere arr worse options? Is that Pirate Case?
- deleted 4y ago[deleted]
- choult 4y agokebab-case = doner meat
- tmtvl 4y agoI'll second that, kebab-case is easy to type, has nice readability, and fits well with regular English constructions like case-sensitive, human-sized, looking-glass, and so on.
- alexisread 4y agoThe problem I've had with kebab case is cross language / devops systems. Some languages and systems don't like kebab case whereas snake case appears more compatible eg. Rpc calls to a named (kebab or snake endpoint).
- djbusby 4y agoDoesn't match \w+
- roenxi 4y agomaybe it is some sort of status thing. since people have to be able to afford a fancy keyboard with a shift key to use camel case or underscores, it shows they can afford nicer things than us kebab-cases. more seriously, it is the unfortunate fact that a lot of systems interpret named-thing and named minus thing. many people don't have the option of using kebab-case. it isn't a good style because it is often impossible to use. which is unfortunate because it is more ergonomic.
- waiting4shoe2 4y agoThe obvious solution is to make `kebab‐case` a name, `kebab−case` a subtraction, and `kebab-case` an error.
- taeric 4y agoI thought this was mainly because of infix math operators?
- txbuck 4y agoThe fact that kebab-case support is a rarity constantly boggles my mind, nevermind that it isn't the de facto default for any language created after *sh/lisp. Readability, ease-of-typing, parallel with the way it's used in (Romantic) natural language. If I were writing a new language I intended to popularize this would be one of the features I would emphasize. Spicy semi-snarky aside: if your counterpoint is that kebab-case prevents crushing your arithmetic operators together, I strongly suggest you either reconsider or never write any code you think may be read by another human being (and possibly yourself).
- Arch-TK 4y agoIt's a bit hard to parse it outside of languages like lisp because of infix.
- thaumasiotes 4y agoInfix has nothing to do with it. We can already parse expressions of the form "x - 20". The change would be to stop interpreting "x-20" as being the same set of three tokens as "x - 20".
- taeric 4y agoThat is the point, though? Is "x- 20" the same as "x - 20" the same as "x -20" In the vast majority of modern programming languages, that is a yes. If you allowed dashes in the names, not so much. Now, I grant the point that it is doable. But the point is it complicate things. Now, fair, we have some of these complications already by virtue of the fact that we allow numbers in variable names. "foo3" is already allowed in many languages, and that clearly gets altered as you add space between the characters.
- thaumasiotes 4y ago> Is "x- 20" the same as "x - 20" the same as "x -20"[?] In the vast majority of modern programming languages, that is a yes. Is that really true? I wouldn't exactly feel comfortable with "x -20", though I suspect you're right about at least a large number of languages determining the meaning of the hyphen through local syntactic context ("I just saw an identifier; that must be a non-unary hyphen"). Now I'm interested in whether the corpus of existing code shows any bias between "y = -x" (perfectly allowed, I think) and "y = -1 * x".
- inopinatus 4y agoI’ve always liked the readability, but interaction is a problem when many UIs treat the hyphen as a break character. Most (all?) browsers do, and even some (albeit not good) IDEs cannot be configured otherwise. When you’re in a hurry, it’s easy to miss a bit off the end.
- layer8 4y agoLuckily Unicode has the non‑breaking hyphen U+2011. This‑is‑a‑long‑identifier‑that‑should‑not‑break‑at‑any‑of‑the‑hyphens.
- inopinatus 4y agoAlas, that doesn't seem to be a general solution. Sure, it doesn't cause line or selection break in my IDEs, nor does it line break in browsers, but it's still a selection break in everything except IDEs (such as all the web and chat services developers use to talk about code), it's harder to type, and as a homoglyph it's super problematic to grep or index identifiers that use it. This last consideration could potentially even increase an attack surface. I'd suggest that it's feasible if we lived our entire developer lives inside a monoculture that adopted it, but that just ain't reality. This all adds up to "why I do not kebab my identifiers".
- infradig 4y agoI had never heard of kebab-case before as kebab refers to cooked chunks of meat.Soon it dawned that shish (meaning skewer) was meant, as in shish-kebab-case. Sorry to be that guy.
- bsder 4y agoThen we have to talk about the devil token which indicates variables/names. You can't have infix minus and kebab case without something to differentiate between the two. Lisp chooses to remove infix minus. Other than old-school BASIC, I don't remember anything else which uses tokens for variables.
- yakubin 4y ago> Lisp chooses to remove infix minus. Infix has nothing to do with it. - refers to the subtraction function regardless of whether it is placed in prefix or infix position. Infix will trigger a type error, not a syntactic error — it will tell you that e.g. it cannot call a fixnum. Lisp quite ordinarily requires function names to be separated from their arguments by spaces, which is just a special case of the rule that atoms need to be separated by spaces. That’s all.
- lispm 4y agoIn many Lisps (+ + +) means this: call the function named + on the two values from the variables named +. The function is then a function object and the values of + can be anything they are currently set to. Thus + serves more than one purpose: function or variable and both may be different values. Thus the position actually matters. What we have below the Lisp syntax are s-expressions: nested lists of symbols and other objects. In s-expressions, symbols need to be separated by whitespace, parentheses or possibly by some special character type (-> terminating character). Characters like +, -, /, *, _, ... are valid characters for any symbols. Thus Lisp does not require functions to be separated by characters but symbols. That's a part of the reader mechanism for reading s-expressions (-> symbolic expression).