Why should size() call be the first line in setup()?

The title says it all.
Most of us here know that size() must be the first call in setup(). @PhiLho also says

... the rule saying that the size() call must be the first one in setup(). For some reason, code before it tends to be run twice, which is annoying when loading a possibly large file.

But why does that occur? Is it because size() internally calls setup() again after setting the size of the sketch, and subsequent calls to size() just skip right through to end?

Answers

  • Answer ✓

    Don't question it. Just do it.

    But yeah, it's something like that.

  • I have always been doing it, almost like sheep keep following....

    But if it is what I thought, then that answers my question.

  • edited February 1 Answer ✓

    Is it because size() internally calls setup() again after setting the size of the sketch, ...

    That was the case before Processing 3. And even so, it didn't affect the default renderer: JAVA2D! :-@

    Therefore, if we had statements before size() within setup(), and only when not using JAVA2D renderer, we had to worry about whether those statements would crash the sketch if they were re-run. :-SS

    For most cases, that'd be innocuous. For example: a file be loaded twice rather than 1. :\">

    When I had to at that time, I'd just declare some boolean variable or test a variable for null.

    static final String IMAGE_FILE = "some_image.png";
    PImage img;
    
    void setup() {
      if (img == null)  img = loadImage(IMAGE_FILE);
      size(img.width, img.height, P3D);
      noLoop();
    }
    
    void draw() {
      background(img);
    }
    

    As n1 can see in my example above, if img isn't null anymore, it means loadImage() had already happened. :ar!

    But even w/o that precaution check, the sketch would work the same, just an annoying double loading. :-\"

    And if it was the default JAVA2D, we could get rid of all of those precautions: ;))

    static final String IMAGE_FILE = "some_image.png";
    PImage img;
    
    void setup() {
      img = loadImage(IMAGE_FILE); // no need for extra precaution here anymore
      size(img.width, img.height); // b/c it's the default renderer JAVA2D now.
      noLoop();
    }
    
    void draw() {
      background(img);
    }
    

    In short, we should avoid using words like: must, have to, ought to, etc.
    B/c in programming, absolute statements can be proven wrong about 99%! :))

  • @GoToLoop So do we need to even worry about it in Processing 3?

  • Answer ✓

    None in P3. And as long it's the default renderer JAVA2D, no glitches for all Processing versions! \m/

    But for aesthetically & organizational purposes, we should favor size() as the 1st statement within setup(). :bz

  • edited February 1 Answer ✓

    It is also a good habit to always call size() first in order to avoid a very common "gotcha" error -- writing code that defines variables based on width or height in setup and forgetting that those variables are initialized to 100 until they are updated by the size() call. (This is also an error that happens if a sketch uses width or height to define a global variable).

    Always keeping size as the first line avoids introducing that category of difficult-to-debug width/height bug into setup later -- especially for newcomers to Processing.

  • Always keeping size as the first line avoids introducing that category of difficult-to-debug width/height bug later

    As much as possible, as most of the examples I post in this forum for many years already, I place size() as the 1st call within setup().

    However, I despise disinformation & censorship being applied to force others to "comply" even to good programming practices. [-(

  • Given that size() gets moved into settings() and executed before setup() is even called, you can put it wherever the hell you want if you want to confuse yourself. It will always execute before any other code in setup().

    Or you could use a real IDE. ;-) I've never understood why these shenanigans are meant to be easier for beginners, but then I learned Java long before touching Processing.

  • Answer ✓

    Well, most Processing programmers don't even know that Processing is merely a Java library! :))

    And those shenanigans do make Java easier for beginners! =P~

  • edited February 2 Answer ✓

    @neilcsmith --

    Given that size() gets moved into settings() and executed before setup() is even called you can put it wherever

    Good point! That is true in Processing 3 by default. Still, "always put size() first" is simple general advice for both Processing 2 -- where that magic-settings-move is not true -- and for Processing 3 -- where in any sketch choosing to override settings(), e.g. to define smooth(), that magic move does not happen. In that case, you still need to put it first -- although first in settings().

  • Thank you for your answers!

  • And those shenanigans do make Java easier for beginners!

    Processing the API and the tools make it great for beginners, no question. This is something that interests me a lot, even if personally I don't think the tools go far enough (or I wouldn't have built Praxis LIVE :-) )

    However, the changes to Java's syntax I'm less sure about - adding a color type that's actually an int that causes confusion and odd bugs, removing the f suffix from floats (don't entirely disagree with doing it, but not like it's done), and primarily moving stuff like size() around so that it doesn't actually execute in the order you've written it and "for some reason" variables don't work.

    To me these are minor tweaks - they're not radical enough to really make a difference to beginners, and are otherwise a hindrance - eg. to supporting other API's based on Java 8 syntax that can (if done right) be really intuitive to beginners.

  • @neilcsmith_net You're right, some of the tools help beginners while causing a lot of trouble to anyone trying to use advanced features, while some other features are just a lot of pain. The color problem and the removal of f are both examples of the latter.

    And some things like the size() problem are really irritating - we're made to follow stupid rules with no justification. And I can quote @TfGuy44 for it-

    Don't question it. Just do it.

  • edited February 3 Answer ✓

    ... , removing the f suffix from floats...
    ... and the removal of f...

    PDE's pre-processor doesn't remove f suffixes from fractional literals. It adds it when there's none!

    Inside ".pde" tab files, if we wanna force a literal to be double, we've gotta suffix it w/ d. #:-S

    It's just the opposite for ".java" tab files: We suffix w/ f to force them to be float. :P

  • Answer ✓

    And you've forgotten to mention that PDE's pre-processor also prefix fields & methods w/ public if there's none there. =P~

    There are some Java libraries defaults imports too. L-)

  • @GoToLoop - note I said the syntax removes the f - the preprocessor obviously adds it back in.

    The boilerplate stuff you mention is (mostly) different in that it involves wrapping the code the user has written, not changing it. There are still better ways of doing it in my opinion though - eg. in the editor.

  • edited February 3 Answer ✓

    note I said the syntax removes the f...

    I still didn't get it. b-( Maybe you've meant? :-/

    note I said the syntax removes the need of f...

    • In Java, all fractional literals are of type double.
    • But Processing decided to use float for its API instead.
    • W/o pre-processor's f suffix auto-insertion, sketches wouldn't compile if we passed fractional literals to Processing's functions. :-&
  • Yes, but you don't need to make weird syntax changes just to support that - you just use double everywhere. :-)

  • That's what I meant too.

    Also note that adding syntax where required only makes it a little confusing for any beginner who also has a small knowledge of Java. In fact, some even get confused to the point that they think Processing is a different programming language altogether.

Sign In or Register to comment.