Where to learn how to code less?

edited December 2015 in General Discussion

I'm interested in elegant coding with the minimum resources used for the same result. Like a poem or short story that has the same impact as a book or long film. Most tutorials or example online only add more clutter to the code which is my usual style of coding. Does anyone know of any resources for this minimalist type of coding in processing?



  • edited December 2015


    The best (or only) way to get better at "minimalist coding" is through experience. Practice programming by actually programming.

    If you have a specific piece of code that you'd like to shorten, then we can try to help you out, but there really isn't a one-size-fits-all approach that answers such a general question.

    Also, welcome to the world of coding. It's messy and cluttered. You should see what code that runs in the real world looks like. I wouldn't worry too much about it.

  • edited December 2015

    Minimalist code is not always elegant. I have seen examples of minimalist code posted on this forum which are unintelligible.

    Probably one of the most important attributes of good software is maintainability. Look at your code, will you be able to easily understand and edit it in 6 or 12 months time? Or more importantly will someone else be able to?

  • edited March 2017

    I totally agree with quark...

    Good code is code that is easy to read and to understand.

    Good code is not necessarily short. On the contrary.

    This means, code can become longer because it is less dense but more explicit and working step by step. Which is good for reading it later. Especially when working as a professional or in a team (or in a forum) this is vital.

    When you have the feeling your code gets convoluted, take a step back.

    There are steps to make the code easier to read. And more elegant


    • let's say you have 10 Asteroids. Some people start with writing a1, a2, a3 and so on. I am sure you don't do that. But of course, you'd turn to an array and for loop over it: asteroids[i]

    • Or people use different vars (like xPos, yPos, widthAsteroid, heightAsteroid...) instead of bringing them inside a class.

    • Or people write a long draw() function instead of breaking it down into functions so draw() is short and elegant. Modularization.

    • Or people don't use good names. Convention: CONSTANTS_IN_CAPITALS, class names big capital and singular (Car), objects small (car) and arrays plurals (cars). Functions are mostly verbs unless they return a boolean.

    But as gotoloop points out there are rules to good programming, e.g. readability or "Don't repeat yourself" (the "DRY principle").

    DRY can be laid out in many ways. E.g. using functions (move a section of your code that occurs often into a function which holds the same functionality more abstract)

    Best, Chrisir ;-)

  • I agree with quark and Chrisir. Clear code is elegant code. Coding to save space leads to ugly code, and is rarely more efficient performance wise.

  • " Look at your code, will you be able to easily understand and edit it in 6 or 12 months time? Or more importantly will someone else be able to?"

    I wish I knew of a more systematic way or recording how a function/method works. I have methods that would take a page and a half of comments to explain how they work, e.g., keeping track of rectangles in relation to other rectangles and transposing their coordinates. I guess thats where all those math symbols come in, but I don't know them. I've written methods a few months ago and still have to struggle with what going on. I guess its because I'm not a mathematician and have to beat it till it works and I forget why it works.

  • you wrote

    I've written methods a few months ago and still have to struggle with what going on. I guess its because I'm not a mathematician and have to beat it till it works and I forget why it works.

    I absolutely feel the same... even in places where I haven't used math really...

  • edited March 2017

    EDIT: Ooops, 2015 didn't read that until after I posted, how did I get here?

    I have one concrete example regarding classes and constructors for simple classes...
    From this tutorial https://processing.org/tutorials/objects/

    class Car { 
      color c;
      float xpos;
      float ypos;
      float xspeed;
      // The Constructor is defined with arguments.
      Car(color tempC, float tempXpos, float tempYpos, float tempXspeed) { 
        c = tempC;
        xpos = tempXpos;
        ypos = tempYpos;
        xspeed = tempXspeed;

    I like to do it like so...

    class foo{ float a,         b,        c;
          foo( float A,   float B,  float C){
                   a=A;       b=B;      c=C;}

    Don't follow rituals like line-break after semicolon, indentation after line-break.
    I'm not saying write everything on one line without spaces, I'm saying do whatever you like because you want it, and not because someone said so.
    Use "taken" names if they make sense
    for example if you want to name a function rect(), you can do that

    void rect(){println("get rect mate");}
    void setup(){rect();} // get rect mate

    Hell you coud name all your functions rect if you really wanted

    void rect(int n){for(int i=0; i<n;i++){rect();}}
    void rect(){println("get rect mate");}
    void setup(){rect(3);}
    // get rect mate 
    // get rect mate
    // get rect mate

    In some cases this may cause problems, but if it doesn't then what's the problem?

    ignore warnings, they're not errors,
    also ignore errors if the code still works(usually it doesn't though) Use ? and : instead of if and else. ? you want to : you don't have to

    If you'we written a piece of code and you're done with it, don't bother commenting it, if you're not done and afraid you may forget something about it, by all means comment and remove the comment when you're done. And move the piece of code away somewhere where it doesn't distract you from what you're currently working on.

    If there is some common practice you like you can follow it of course,
    no reason to be rebellious for the sake of it.

  • edited March 2017

    I disagree.


    I mean if you just do it for the fun of it, go ahead.

    But if you want to get somewhere with your hobby and come across your own code a few month later or want to reuse your code in another project or do bigger projects you need to be able to fully read and understand your code to make sense of it.

    Therefore: write readable code, don't invent functions with names that already exist. E.g. don't use draw in a class, use display.


    When you work in a professional environment, you wouldn't allowed to write code like this in the first place.

    The most important thing when working on a team is communication.

    So to communicate with or through code you have to have good code.

    There are books on this.



  • @Chrisir I disagree with one of your points, inside any class that doesn't already have a draw function, you should name the function as draw(). Because it is to be called only inside draw (of main sketch), it will be easy to understand. Besides, the highlighting done by Processing IDE also helps.

  • this was posted today:


    don't do this.

  • Hilarious!

  • And I thought that such things were done just for fun :))

  • edited March 2017

    It's lacking spacing there! Anything as such is like an enigma to read after all: :-@

    sliderX = sliderX > 0? 0 : sliderX < w-mW? w-mW : sliderX;

    But that conditional assignment expression would be much clearer w/ constrain() instead: *-:)

    sliderX = constrain(sliderX, w-mW, 0);


Sign In or Register to comment.