I noticed that when I write code that is not trivial to understand I tend to extract intermediate values into variables with meaningful names.

    applyDrag(): void {
        const { quad: quadConfig } = settings
        const quad = this.getRigidBody()
        const quadVel = vec3ToTwgl(quad.linvel())
        const dragMag = aerodynamicDrag(quadConfig.dragCoefficient, v3.length(quadVel), quadConfig.frontalArea)
        const dragDir = v3.negate(v3.normalize(quadVel))
        const dragForce = v3.mulScalar(dragDir, dragMag)
        const dragImpulse = v3.mulScalar(dragForce, dt)
        quad.applyImpulse(vec3TwglToRapier(dragImpulse), true)
    }

This way code gets more natural language anchors which helps understanding what it does.

▲ codemonkey-zeta 4 days ago | parent | next [-]

I find that Lisps encourage this behavior more than other languages. Many (most?) of the lisp functions I read have the exact same structure:

  (fn some-function [args]
    (let [binding (transform args)]
      (an-expression binding)))

I find that this makes skimming lisp code much easier, because I can usually skip reading the bindings and just read the function name and ultimate expression and usually get the gist very quickly.

You might wonder how this is different than the example you provided, and the answer is because you could sneakily intersperse anything you wanted between your imperative bindings (like a conditional return statement), so I actually have to read every line of your code, vs in a lisp `let` I know for a fact there is nothing sneaky going on.

	▲	ivanjermakov 4 days ago \| parent [-]
		It's the same for many FP/pure languages, where function is a single expression.

▲ TZubiri 3 days ago | parent | prev | next [-]

Funny how even in this very verbose code (which is perfectly fine btw), there's still a need to use shorthands (quadVel). It's like completely explained code requires so many words, but we need to fit the code into a certain character window.

▲ necrotic_comp 4 days ago | parent | prev | next [-]

I appreciate this way of programming - also, if I may, in the age of auto-complete I think it's okay to have verbose variable naming. Imho, it's perfectly fine to have quad, quadVelocity, dragMagnitude, etc.

I see this a lot in the wild, though - as an honest question (not trolling!) why do people still shorten their variable names in place of having a terse descriptor ?

	▲	ivanjermakov 4 days ago \| parent [-]
		I tend to have shorter names for function scoped variables. Wider the scope - more descriptive the name. Short names are good to have more concise code and more logic fitting into a line width.

▲ 8note 2 days ago | parent | prev [-]

you can get a few more anchors in with a builder:

   aerodynamicDrag(DragInput.builder()
        .dragCoefficient(quadConfig.dragCoefficient), 
        .speed(v3.length(quadVel))
        .referenceArea(quadConfig.frontalArea)
        .build()
    )

which i think points at a possible bug where there drag coefficient isnt measured for the frontal area and needs to be rescaled?