3
\$\begingroup\$

I have been reading and writing both GLSL and CG for the past few years, and have noticed a trend. In programming, we are generally advised to be as meaningful and concise as possible with variable names, but I see this suggestion being ignored almost every time I look at shaders.

Here is a random example I grabbed off of Shadertoy:

vec3 tex_wmcs(vec2 p)
{
    float s=mix(0.2,1.2,sqrt(smoothNoise2(p*3.0)));
    vec3 col=mix(vec3(0.15,0.2,0.2)*0.4,vec3(0.2,0.15,0.11)*0.7*s,sqrt(max(0.0,sm...
    vec2 p2=p*vec2(4.0,10.0)+vec2(smoothNoise2(p*24.0),smoothNoise2...
    p2.x+=floor(p2.y)*0.5;
    float bh=pow(0.5+0.5*cos(floor(p2.y)*14.0)*cos(floor(p2.x)*1.0),2.0);
    float brick=brickt(p2);
    vec3 bn=normalize(vec3(brickt(p2+vec2(1e-3,0.0))-brick,b...
    ...
}

Is there a practical reason so many graphics programmers minify their code to such a point?

Is there a technical downside to spelling out brickNormal instead of leaving it as bn, or using brick_tangent or brickTexture instead of brickt?

\$\endgroup\$
1
  • 1
    \$\begingroup\$ For reference, you can use gpuopen.com/archive/gpu-shaderanalyzer to see how shaders are compiled. (It's also neat for seeing how amazing shader compilers are). \$\endgroup\$ Commented Sep 27, 2018 at 17:18

3 Answers 3

Reset to default
9
\$\begingroup\$

I've noticed the same trend, I've found the following reasons apply:

Shadertoy in particular is just that a toy. You will often find people don't bother with good coding standards and do what ever is quickest because typically you aren't collaborating with any one else and are just trying to show off a visual effect.

Code Golfing esque programming: lots of shaders pride themselves on being short to the extreme in order to show off "look what I can create with only 50 chars! The short nature of shaders makes this much more prevalent, which leads into my next point:

Shaders, by their nature, are meant to be very short. Due to the lack of built in ability to share code between shaders, and the single function typical use case of shaders (they are used to usually do one thing) shaders typically are shorter than most single source files in C and C++. You'll often find advanced shaders using very few lines of code (under 100). If you can see the whole code on your screen and it only fits in a couple of functions, it's going to be easier to reason about it no matter how small the variable names are.

And to bring this back around, you'll often find very large shaders on shader toy (because some of these things don't apply) but the legacy of how other shaders are programmed means that you are going to see people copying the very poor style of these other programmers.

Don't follow these practices. There is no reason you can't apply normal readability principles in shadertoy or in individual GLSL shaders. There isn't any practical justification for the shortness unless you're code golfing. There is no technical reason to shorten the names either.

\$\endgroup\$
6
\$\begingroup\$

Some possible reasons for using short variable names are:

  • Brevity: short variable take less time to type.
  • Following Textbooks: similar to the discussion in this software engineering SO post on short variable names, some shader code might be written using formulas from textbooks (physics, optics, math, etc) and it's common for such formulas to use abbreviations & established variables (such as often using theta for angles). Academic papers often share this trait as well (some cutting edge techniques often start research presented in places like SIG Graph). Some programmers may carry this style over to other parts of the code.
  • Historical Precedent: originally, shaders were essentially written a GPU specific assembly language. Assembly code is very terse. It's possible that some of the this style has been adopted by subsequent generations.
  • (Perceived) Memory Efficiency: As discussed here, in some cases (very old compilers, and certain interpreted languages), longer variable names take up more memory than shorter ones. Even if this doesn't apply to modern shaders, some programmers may be following cargo cult programming practices.

In my professional opinion, the only reason that holds up is the textbook/other source example and then only under certain circumstances. In the event that your developing code from other formulas presented elsewhere, using the same variable names can make it easier to compare your translation to the original. After having done that & in the other cases that come to mind, the correctness, clarity & maintainability should be focus for producing well crafted code.

\$\endgroup\$
3
  • \$\begingroup\$ Since most shader code (as shown in the example) isn't following textbook formulas, and that your other points don't really excuse the use of short names since there are no benefits today, are you saying there is no technical advantage? \$\endgroup\$ Commented Sep 27, 2018 at 19:22
  • \$\begingroup\$ @SamVanAllen I was focusing more on the aspects that I could back up factually. In terms of professional opinion, I personally aspire to write understandable code. But I've also written some fast & terse code that wasn't intended for further use & then got used more anyway. I've updated my answer a bit to include my professional opinion, but the short reply to your question in comment is 'no, not really'. \$\endgroup\$ Commented Sep 27, 2018 at 23:05
  • 2
    \$\begingroup\$ @SamVanAllen I'm pretty sure there is no technical advantage at all. Maybe when it mattered people made small variable names, and it got stuck as a habit? I, for example, still use variable names like pos and n for vertex positions and normals, out of habit because of all the tutorials I've seen using it, that it now makes sense. \$\endgroup\$ Commented Sep 28, 2018 at 8:24
1
\$\begingroup\$

Small scopes and math operations both "call" for short variable names:

  1. Small scope means you have just a bunch of operations to do with just a few variables. Keeping variable names short allows for sense of compactness (which many programmers like).

  2. Many of shader operations are following some math formulas. Math formulas are known for short var names (x, y, dt, etc.), hence shorter var names.

Both reasons are kind of justified to some extent, but once code surpasses few lines and a few variables, it's better to let go of compactness and spend some time to give variables proper names, write some comments.

\$\endgroup\$

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.