Topic outline

  • Kia ora Guest user

    Welcome to CGI506 Technical Development 1, S2-20. In this course you will be developing basic skills and knowledge of programming for animation and game development and to develop custom tools and functions for a successful production pipeline.

    On completion of this course you will be able to:

    1. Investigate and compare different programming languages used for animation, visual effects and real time applications. 
    2. Evaluate the effectiveness of different scripting/programming languages for selected applications. 
    3. Select and use a number of different scripting languages to achieve the desired effects and tools.  
    4. Create custom tools to facilitate a production scenario. 

    Alongside the class time and your project work, you will be provided with extra learning material, videos and tasks to help you improve your skills.  Work at your own pace spending roughly 4 hours a week on these. 

    All courses in this programme include an assessment of professionalism. Professionalism includes your active engagement in class activities, your ability to communicate with your peers and tutor, how you work in a team and more importantly how you manage your self.

    Usually we cover one session per week. Note this course content and schedule, may be adjusted as we understand more about our needs as a group of learners. 

  • Session 7 - Developer Skills

    We will develop our skills as developers ;-) !

    Run this in your shell:

    >>> import this
    Beautiful is better than ugly.
    Explicit is better than implicit.
    Simple is better than complex.
    Complex is better than complicated.
    Flat is better than nested.
    Sparse is better than dense.
    Readability counts.
    Special cases aren't special enough to break the rules.
    Although practicality beats purity.
    Errors should never pass silently.
    Unless explicitly silenced.
    In the face of ambiguity, refuse the temptation to guess.
    There should be one-- and preferably only one --obvious way to do it.
    Although that way may not be obvious at first unless you're Dutch.
    Now is better than never.
    Although never is often better than *right* now.
    If the implementation is hard to explain, it's a bad idea.
    If the implementation is easy to explain, it may be a good idea.
    Namespaces are one honking great idea -- let's do more of those!

    This is an Easter egg hidden in Python. Meditate on it, and be sure to come back to it in the future. It will mean different things to you as you learn to code.

    Code should do what we expect:
    With the principles of user experience and design, code we write should generally be clear in meaning, and do what we expect. These are the guiding principles of user-centered design, and ones that can help us in designing the code that we write. Generally other people are going to work on our code too, and so, things should work as they’d expect. Now of course if one doesn’t have the experience as a developer, they may not be familiar with conventions or how things should be done, but don’t sweat this. With experience all things become easier.

    This means taking the time as you write to consider how you name and structure things.

    What does it mean to be “Pythonic”?

    From Infogalactic (Wikipedia):

    A common neologism in the Python community is pythonic, which can have a wide range of meanings related to program style. To say that code is pythonic is to say that it uses Python idioms well, that it is natural or shows fluency in the language. Likewise, to say of an interface or language feature that it is pythonic is to say that it works well with Python idioms, that its use meshes well with the rest of the language.

    In contrast, a mark of unpythonic code is that it attempts to write C++ (or Lisp, Perl, or Java) code in Python—that is, provides a rough transcription rather than an idiomatic translation of forms from another language. The concept of pythonicity is tightly bound to Python's minimalist philosophy of readability and avoiding the "there's more than one way to do it" approach. Unreadable code or incomprehensible idioms are unpythonic.

    Use keyword arguments wherever possible:

    My personal take on this, and one observation that we can begin doing straightaway -- is using specifying the full keyword arguments whenever possible. Explicit is better than implicit. For example:

    # no keyword arguments, this is harder to read
    do_something('/path/thing.exr', ['char', 'bg'], True)
    # vs keyword arguments, this is easier to read
    do_something(path='/path/thing.exr', filter=['char', 'bg'], follow_links=True)

    Python also lets you place things inside parentheses, however you like for readability:

    do_something(
       path='/path/thing.exr',     
       filter=['char', 'bg'],
       follow_links=True)

    What are some ways your programs can be improved?

    Optionally, for further reading:

    https://docs.python-guide.org/writing/style/

     

    Editing Python:

    I would like to suggest a couple of advanced editors, Atom or Sublime Text.

    Both can be extended with plugins to make your python editing experience smoother, and easier to read with context sensitive highlighting.

    Atom:Whichever editor you decide to use, be sure to look up an introductory tutorial and explore some of the more advanced features for refactoring code, multi-select, and so on.

    Naming Conventions: which case do I use?

    This is just my personal preference from the studios I’ve worked at. The primary objective is to be consistent in your modules.

    Why use naming conventions? It gives you a sense of what looks good, feels correct in code, and it makes it easier to understand someone else’s code if they follow the same conventions as you do.

    • Variables: Underscore case. “is_validated”, “num_cherries”, “user” are all great variable names. Lower case words separated by underscores.

    • Functions: I also uses underscore case here, but some companies or frameworks use camel case, which looks like “camelCase”. Upper case first-letters of every word except the first word which is all lower case. “validateSequence”.  Also important is to name your functions in a way that indicate what they do, in verb form. Like “submitRender” or “safetyCheckSequence”.

    • Classes: PascalCase. Like camelCase but every word has its first letter capitalized, including the first. E.g. “AbstractSequence” or “PolyCube”.

    • Globals: UPPER-CASE. If it’s a variable, a fixed constant that does not change, but acts as a switch mechanism, we often write it as all upper case. Like “CONFIG”. Use sparingly, all caps is hard to read!