Haxe

but even then, i wouldnt accept a "if (!condition) return;"

naahhh the ! thing is too universal its not that advanced of a concept

```haxe
if (!condition) {
    return;
}
```

ill only end up changing it later for consistency

why the `{}` tho, its always the same line after the if - `return;`

i might omit the brackets if i'm being lazy but i'd probably go for the extra newline just for the sake of readability

with the corporates i work with, we lint all that stuff, and so you get into the habit

it's good to set up a checkstyle file for stuff like this i guess

there is one for haxeui somewhere, but iirc, haxeui is really inconsistent, i mean, look at `var scaleW:Float = maxWidth != -1 ? maxWidth / image.originalWidth : 1;` which was already there

```hx
var scale = switch (imageScaleMode) {
    case ScaleMode.FIT_INSIDE:
        (scaleW < scaleH) ? scaleW : scaleH;
    case ScaleMode.FIT_OUTSIDE:
        (scaleW > scaleH) ? scaleW : scaleH;
    case ScaleMode.FIT_WIDTH:
        scaleW;
    case ScaleMode.FIT_HEIGHT:
        scaleH;
    default: // ScaleMode.NONE
        1;
}
```
For your own projects you can also do this in haxe :3

but - one thing - please change the `== true`, its bullying material 😂

at the very least if, i wrote that it would be: `var scaleW:Float = (maxWidth != -1) ? maxWidth / image.originalWidth : 1;`

yeah i know, but i find it hard to keep track without the brackets, so i mostly unline those

no need to write `scale = ` every case is the main point of that example

the == true thing im totally on the fence about, i never use it anywhere else except in haxe for some reason

you can actually have case brackets as well in haxe if you want

```hx
switch (foo) {
  case Boo: {
  }
  default: {
  }
}
```

honestly i would even be tempted to put the checks as part of the pattern, but i guess it might depend on the situation whether its practical

yeah, for this particular example and this usecase i'd actually opt for shah's initial screenshot

they usually acrew up indentation, wierd bug. haxe likes to indent the brackets to and treat it as a code block:
```haxe
switch f {

  case e: {
    //this is how code is formatted. ew
    }
  case f:
}
```

you can change the formatting to what you want it to be

anyway, lets be frank, unless you are willing to change the code style for the _entire_ codebase (and we could even agree on one) this is a non starter