6 ms·

Kebab-case is, in my opinion, the most beautiful of identifier cases, but how would you get around the ambiguity with subtraction, short of going full Lisp or a

Kebab-case is, in my opinion, the most beautiful of identifier cases, but how would you get around the ambiguity with subtraction, short of going full Lisp or adding whitespace sensitivity?

wtetzner 8y ago
> adding whitespace sensitivity? Would adding whitespace sensitivity really be a problem? You already need whitespace to separate identifiers, so it's not a totally foreign concept in mainstream languages. It seems like we've been making a weird trdeoff, by disallowing kebab-case just so we can smash our operators together with our operands.
- phkahler 8y ago
  >> It seems like we've been making a weird trdeoff, by disallowing kebab-case just so we can smash our operators together with our operands. Some people don't want to bother putting a space between operators and operands, and proponents of kebab-case just don't want to push the shift key to get an underscore.
  - ModernMech 8y ago
    As the other poster mentioned, you gain more than just the dash when forcing white space; you get forced readability and characters like / ? and ^ in identifiers. Then you can name things like foo/bar or e^x
    - mikepurvis 8y ago
      I suppose I could get used to that, but it sounds like a nightmare at first blush.
    - plopz 8y ago
      I don't think I could handle i ++ instead of i++
      - mort96 8y ago
        You wouldn't have to require whitespace around all operators; you could, for example, decide that infix math/bitwise/logic operators must have a space around them, while other operators (like the infix operators `.` and `->`, and the prefix/suffix `++`, `--`, `[...]`, and `!`) wouldn't require whitespace. I agree that nobody would want to write `i ++` or `foo [10]` or `myvar . mymember`, but I think a lot of people could get behind `10 - 20` and `foo && bar` instead of `10-20` and `foo&&bar`.
  - deleted 8y ago
    [deleted]
  - wtetzner 8y ago
    To get kebab-case, the restriction that identifiers cannot start or end with '-' gets you pretty far. The only whitespace change is that you sometimes need whitespace around an infix '-'. Other operators are still fine, and it still works fine for prefix and postfix operators. Also, the reason to prefer kabab-case for me has nothing to do with avoiding a keypress. It's that I find kebab-case easier to read.
- blt 8y ago
  I generally separate operands, but in dense math expressions it's not always the best for readability. x = (-b + sqrt(b**2 + 4*a*c) / (2*a) x = (- b + sqrt(b ** 2 + 4 * a * c) / (2 * a) ... Although, one could argue that allowing tightened multiplication and division are enough.
  - AnimalMuppet 8y ago
    Not to be that guy, but... x = (-b + sqrt(b**2 - 4*a*c) / (2*a)
    - blt 8y ago
      lol, thank you.
  - wtetzner 8y ago
    Well, if you're only interested in kebab-case, then specifying that identifiers can't start or end with hyphens solves most of the problem. The only restriction would be that you'd need whitespace around '-' only when used as an infix operator.
- m48 8y ago
  Does one actually need whitespace to separate identifiers? This is something that's always bugged me a bit. Aside from C-style type declarations ("unsigned int x;"), C-style syntaxes seem to always have ways other than whitespace to separate identifiers. Like (using some JavaScript in a hypothetical example) I can't think of many concrete reasons why this is easier to parse: let first_number=2, second_number=2, answer=first_number-second_number; ...than this: let first number=2, second number=2, answer=first number-second number; Although, of course, some languages—most Lisps, Tcl, and Red/REBOL come to mind—actually do rely on whitespace and whitespace alone to separate identifiers in many situations, and something like this would likely be unworkable there.
  - mkl 8y ago
    TikZ allows whitespace in identifiers. At first it was pretty strange, but I actually really like it now. I don't think parsing it is much of a problem, and I would quite like to be able to use it in other languages.
    - m48 8y ago
      Well, thinking about it more, I did realize there's a pretty nasty edge case with my hypothetical JavaScript syntax: let let x = 5; let x = 6; // should this set the variable "let x"? // or define a variable named "x"? One could potentially design around situations like this, but allowing whitespace in identifiers likely does require being much more meticulous about treatment of reserved words, identifiers, and whitespace than more traditional syntaxes, and this is likely why not many people attempt this. I think the idea is worth experimenting with, though, and that a good implementation of it could be convenient enough for end-users to outweigh the implementation inconvenience.
  - lispm 8y ago
    Though one can use whitespace in Common Lisp identifiers, by quoting symbols: CL-USER 115 > (let ((first| |number 10) (second\ number 20)) (+ first\ number |SECOND NUMBER|)) 30
mort96 8y ago
I don't think requiring whitespace around operators is such a bad thing. My personal coding style generally looks like `int foo = 10 + (something - 20);` anyways, and I think that style is a lot more readable than `int foo=10+(something-20);`. If you require whitespace around almost all operators, you open up the possibility of naming identifiers basically anything, which lets you have conventions like naming predicates or boolean members with a question mark at the end. In my opinion, `myObject.whatever?` looks a lot better than `myObject.isWhatever`. Exactly which operators should require whitespace and which don't is up for debate, but in my personal opinion, requiring space around infix operators and letting prefix/postfix operators not require a space would be appropriate. Nobody wants to have to write `myArray [i]`, but I think most people would be willing to give up `i-1` and instead write `i - 1`.
- sacado2 8y ago
  I like to be able to remove spaces in complex expressions, for readability issues. For instance, this : t[x] = t[x-1] + t[x-2] looks more readable to me than this : t[x] = t[x - 1] + t[x - 2] Another example : y = a*x1 + b*x2 + c
tzs 8y ago
Use +- for subtraction, where + is binary plus and - is unary minus.
kps 8y ago
Use ‘−’ for subtraction, allow ‘–’ and ‘‐’ in identifiers, and report an error for ‘-’.
- mort96 8y ago
  Sure, just make everyone replace their keyboard with one which has two `-` buttons and make everyone understand why they need two buttons for something which looks like the same letter and you can safely use – for one thing and — for the other.
a1369209993 8y ago
Not sure if it's a good idea, but maybe try: foo-bar # kebab-case foo−bar # subtraction foo minus bar # subtraction? (infix identifier "minus") foo - bar # subtraction (infix identifier "-") foo − bar # subtraction (operator symbol) using \u2212 as a explicit subtraction operator for people who really can't stand having 'extra' whitespace?
slobotron 8y ago
Perl6 allows it, and it's the preferred convention to boot. Small Intro: https://perl6advent.wordpress.com/2015/12/05/day-5-identifiers-have-hyphens-in-them/ https://perl6advent.wordpress.com/2015/12/05/day-5-identifie...

Kebab-case is, in my opinion, the most beautiful of identifier cases, but how would you get around the ambiguity with subtraction, short of going full Lisp or adding whitespace sensitivity?

wtetzner 8y ago

> adding whitespace sensitivity? Would adding whitespace sensitivity really be a problem? You already need whitespace to separate identifiers, so it's not a totally foreign concept in mainstream languages. It seems like we've been making a weird trdeoff, by disallowing kebab-case just so we can smash our operators together with our operands.

phkahler 8y ago
>> It seems like we've been making a weird trdeoff, by disallowing kebab-case just so we can smash our operators together with our operands. Some people don't want to bother putting a space between operators and operands, and proponents of kebab-case just don't want to push the shift key to get an underscore.
- ModernMech 8y ago
  As the other poster mentioned, you gain more than just the dash when forcing white space; you get forced readability and characters like / ? and ^ in identifiers. Then you can name things like foo/bar or e^x
  - mikepurvis 8y ago
    I suppose I could get used to that, but it sounds like a nightmare at first blush.
  - plopz 8y ago
    I don't think I could handle i ++ instead of i++
    - mort96 8y ago
      You wouldn't have to require whitespace around all operators; you could, for example, decide that infix math/bitwise/logic operators must have a space around them, while other operators (like the infix operators `.` and `->`, and the prefix/suffix `++`, `--`, `[...]`, and `!`) wouldn't require whitespace. I agree that nobody would want to write `i ++` or `foo [10]` or `myvar . mymember`, but I think a lot of people could get behind `10 - 20` and `foo && bar` instead of `10-20` and `foo&&bar`.
- deleted 8y ago
  [deleted]
- wtetzner 8y ago
  To get kebab-case, the restriction that identifiers cannot start or end with '-' gets you pretty far. The only whitespace change is that you sometimes need whitespace around an infix '-'. Other operators are still fine, and it still works fine for prefix and postfix operators. Also, the reason to prefer kabab-case for me has nothing to do with avoiding a keypress. It's that I find kebab-case easier to read.
blt 8y ago
I generally separate operands, but in dense math expressions it's not always the best for readability. x = (-b + sqrt(b**2 + 4*a*c) / (2*a) x = (- b + sqrt(b ** 2 + 4 * a * c) / (2 * a) ... Although, one could argue that allowing tightened multiplication and division are enough.
- AnimalMuppet 8y ago
  Not to be that guy, but... x = (-b + sqrt(b**2 - 4*a*c) / (2*a)
  - blt 8y ago
    lol, thank you.
- wtetzner 8y ago
  Well, if you're only interested in kebab-case, then specifying that identifiers can't start or end with hyphens solves most of the problem. The only restriction would be that you'd need whitespace around '-' only when used as an infix operator.
m48 8y ago
Does one actually need whitespace to separate identifiers? This is something that's always bugged me a bit. Aside from C-style type declarations ("unsigned int x;"), C-style syntaxes seem to always have ways other than whitespace to separate identifiers. Like (using some JavaScript in a hypothetical example) I can't think of many concrete reasons why this is easier to parse: let first_number=2, second_number=2, answer=first_number-second_number; ...than this: let first number=2, second number=2, answer=first number-second number; Although, of course, some languages—most Lisps, Tcl, and Red/REBOL come to mind—actually do rely on whitespace and whitespace alone to separate identifiers in many situations, and something like this would likely be unworkable there.
- mkl 8y ago
  TikZ allows whitespace in identifiers. At first it was pretty strange, but I actually really like it now. I don't think parsing it is much of a problem, and I would quite like to be able to use it in other languages.
  - m48 8y ago
    Well, thinking about it more, I did realize there's a pretty nasty edge case with my hypothetical JavaScript syntax: let let x = 5; let x = 6; // should this set the variable "let x"? // or define a variable named "x"? One could potentially design around situations like this, but allowing whitespace in identifiers likely does require being much more meticulous about treatment of reserved words, identifiers, and whitespace than more traditional syntaxes, and this is likely why not many people attempt this. I think the idea is worth experimenting with, though, and that a good implementation of it could be convenient enough for end-users to outweigh the implementation inconvenience.
- lispm 8y ago
  Though one can use whitespace in Common Lisp identifiers, by quoting symbols: CL-USER 115 > (let ((first| |number 10) (second\ number 20)) (+ first\ number |SECOND NUMBER|)) 30

mort96 8y ago

I don't think requiring whitespace around operators is such a bad thing. My personal coding style generally looks like `int foo = 10 + (something - 20);` anyways, and I think that style is a lot more readable than `int foo=10+(something-20);`. If you require whitespace around almost all operators, you open up the possibility of naming identifiers basically anything, which lets you have conventions like naming predicates or boolean members with a question mark at the end. In my opinion, `myObject.whatever?` looks a lot better than `myObject.isWhatever`. Exactly which operators should require whitespace and which don't is up for debate, but in my personal opinion, requiring space around infix operators and letting prefix/postfix operators not require a space would be appropriate. Nobody wants to have to write `myArray [i]`, but I think most people would be willing to give up `i-1` and instead write `i - 1`.

sacado2 8y ago
I like to be able to remove spaces in complex expressions, for readability issues. For instance, this : t[x] = t[x-1] + t[x-2] looks more readable to me than this : t[x] = t[x - 1] + t[x - 2] Another example : y = a*x1 + b*x2 + c

tzs 8y ago

Use +- for subtraction, where + is binary plus and - is unary minus.

kps 8y ago

Use ‘−’ for subtraction, allow ‘–’ and ‘‐’ in identifiers, and report an error for ‘-’.

mort96 8y ago
Sure, just make everyone replace their keyboard with one which has two `-` buttons and make everyone understand why they need two buttons for something which looks like the same letter and you can safely use – for one thing and — for the other.

a1369209993 8y ago

Not sure if it's a good idea, but maybe try: foo-bar # kebab-case foo−bar # subtraction foo minus bar # subtraction? (infix identifier "minus") foo - bar # subtraction (infix identifier "-") foo − bar # subtraction (operator symbol) using \u2212 as a explicit subtraction operator for people who really can't stand having 'extra' whitespace?

slobotron 8y ago

Perl6 allows it, and it's the preferred convention to boot. Small Intro: https://perl6advent.wordpress.com/2015/12/05/day-5-identifiers-have-hyphens-in-them/ https://perl6advent.wordpress.com/2015/12/05/day-5-identifie...