Learning Coding Methodologies

Coding
1

I’ve been diving into coding pretty hard for the past 1.5-2 years (python primarily). It has been extremely eye opening about how everything (or, at the very least, a lot of stuff) works but I feel like I am missing out on a lot by not having a full grasp of common coding methodologies and standards. I have tried to pick it up as I go by reading other people’s code and learning from forums and what not, but, I have very, very little formal coding education so proper coding standard are not exactly ingrained. Do you guys have any suggestions on how to learn good coding methodologies (books or tutorials or what have you)?

Thanks,
Berryman

2

Having searched for the same, the only conclusion i could come to is to just stick a methodology, there’s plenty of 'm around, but stick to one or document your own methodology for others.

Depending on my dependencies to a module i’ll either use PEP-8 or the Google style guide.

If we use PySide or PyQt we go for a customized Google style guide (CamelCase functions, but 4 space indent)

I’m really curious as to what other have to chime in on this subject.

Sven

3

Are you talking about paradigms, design patterns, coding conventions?

4

Not sure of methodologies, but there are some rules to stick to and notice ugly code. Also check the zen of python

> python -c "import this"

A couple off the top of my head:

  • no magic numbers. If you have an expression like this:

if len(nodes) > 4:
    ## do something

Why 4? What’s the significance? Assign to a variable first so its descriptive

  • Dont use complicated list comprehensions, just dont
  • Dont use *, ** magic. Its combersome to debug and looks ugly
  • Pick a convention and stick to it. Doesn’t matter what it is, as long as your code is homogeneous
5
  • and ** can be incredibly useful for handling and passing arguments, why would you blanket recommend against it?
6

Its useful for say, calling super on something like a qt widget. Thats fine. What i meant was


def myFuncA(a, b=True, c=None):
    ## -- Do something

def myFuncB(*args, **kwargs):
    myFuncA(*args, **kwargs)

Whne myFuncB gets a bug, you’ll have no idea whats coming in. Is b True or False? is c even passed in? Who knows :slight_smile: Theres no quick way to see whats going on.

7

Docstrings, I’ve been using them lately and they’ve been pretty useful to me. Also it’s very good when you want to have your code shared or when working in a team. PEP 257 – Docstring Conventions | peps.python.org

8

I’d recommend reading The Art of Readable Code - it’s got a lot of hints that work well regardless who you like in the big theological divisions in programming paradigm land.

If you’re making the transition from script style do this, do that to object oriented programming, you might find Thinking in Python helpful. Head First Object Oriented programming is also not bad for getting aquainted with the ideas beyond the ‘duck.quack()’ level.

9

I know what you mean. I had a job lately where i discovered that i needed to raise my design/code architecture skills. While i have a formal education on programming, and i would consider myself one of the (rare!?) programmers that always value readability, maintainability over performance (at least on the first iterations) maybe only knowing the language intricacies/knowing the OO basics sometimes doesnt take you all the way. I felt like i needed to get an understanding of the bigger picture, thats why i lately read a book about design patterns. While many buddies have deemed that uneccessary for plugin writing, i think it always helps!

10

[QUOTE=timmwagener;23420]I know what you mean. I had a job lately where i discovered that i needed to raise my design/code architecture skills. While i have a formal education on programming, and i would consider myself one of the (rare!?) programmers that always value readability, maintainability over performance (at least on the first iterations) maybe only knowing the language intricacies/knowing the OO basics sometimes doesnt take you all the way. I felt like i needed to get an understanding of the bigger picture, thats why i lately read a book about design patterns. While many buddies have deemed that uneccessary for plugin writing, i think it always helps![/QUOTE]

You might want to look into software engineering, which concerns itself with application architecture, the software lifecycle, re-use, maintainability, development methodologies and system design. In general you would find programmers who’re good with designing system (i.e. software engineers), and programmers who’re subject matter experts for a particular area, e.g. 3D programming, GPU programming, databases, etc. It’s a specialization big-picture vs. details.

For example you may have a guy in the team who’s really good at writing Max plugins, knows the Max API inside out. Yet that guy may not be the right person to get the picture of designing a big pipeline, consisting of many components, and being developed in many different languages.

In software engineering, and actually in any professional development setting, maintainability and re-usability always comes before performance, always! That’s the same reason why we don’t overclock our workstations. Reliability and robustness is king, and downtime and time spend on maintenance is bad! Sure performance is important, but it should never compromise reliability and maintenance. Performance wins are usually not that big, and the time gained is usually less than the time you lose if your software is crap and causes problems.

Anyway, I can recommend the following books:
“Software Engineering for Game Programmers” by Flynt is a good intro to software design and engineering (I think you can ignore the UML, although being able to read UML diagrams makes understanding those pattern books easier!; and ignore that the example game sucks). The book pretty much covers what a good SE textbook would cover, like Sommerville’s Software Engineering (but that one costs you an arm and a leg!)

“The Object Oriented Though Process” by Weisfeld is also a good intro to OO. But maybe more interesting for people who didn’t do much OO - i.e. you’re coming from Max Script or another language with questionable OO implementation.

“Code Complete 2” by McConnell - definitely get that one. Should be in every programmer’s library. Very readable, very solid advice how to write readable, solid and maintainable code. Can be applied to pretty much any language. I also found “The Pragmatic Programmer” a good read, but it feels a bit more abstract. Also covers ideas, programming philosophies and approaches for better code and more robust applications.

“Design Patterns” by Gamma is definitely the classic patterns book. Get it. But I don’t recommend it as first book as the patterns are not very concrete (but you will learn the power of this later, as you get into looking for patterns). Plus the examples are in C++. Instead I recommend getting Fowler’s “Patterns of Enterprise Software Architecture” first. The patterns feel less abstract and more focused, and they’re all presented in Java, which is basically C#. If you’ve worked with HTML or databases you will quickly recognize the patterns and get the whole pattern idea. After that, move to Gamma. Design patterns are a big part of the whole reuse idea, as the solutions presented by patterns can be reused.

Regarding your friends’ views, I would say that we will find both people in the TA tools coding field, and that eventually you may want to decide what to focus on - for example specialize in algorithms, APIs, 3D math to become the best programmer for highly specialized code, or get the knowledge so you can design bigger systems, like pipelines, content management system, and understand how to make it all work together. But both groups of programmers need each other when designing a big system. In any case, the time for “script kiddy TAs” is over. If you cannot program maintainable and reusable code: get out… or learns something new and adapt :wink:

[QUOTE=Theodox;23418]I’d recommend reading The Art of Readable Code - it’s got a lot of hints that work well regardless who you like in the big theological divisions in programming paradigm land.[/QUOTE] Interesting. Thanks for sharing.

11

As I primarily write tools, have longed for some sort of Tool Programming specific guide.

A lot of design patterns I find are presented in too abstract, with examples I have difficulty relating to daily tasks.
Add to this, help file examples and (other) forum searches result often yield poorly organized code
I feel I just get a lot of trial and error combined with slow discovery…

12

I really liked “The Pragmatic Programmer” as Robert said though, it’s more abstract.

There was also a really great section in Game Developer magazine about cleaning up bad code a while ago, which was also on Alt Dev.

13

Great topic, two books have already caught my attention. My experience is similar to that of the OP, followed by a year of full-time pipeline programming with Python and Qt. Here are some books that have helped me a lot.

API Design for C++. Although not Python oriented, he talks about concepts and how to organize your code relative to separating your interface from your implementation. I’ve found that a lot of the same conteps also apply to rigging, as rigs are more or less an implementation with an interface for animators.

Game Engine Architecture helped me in understanding how vast and complex software can get and how to organise it in a way that makes sense to you and those around you.

The Art of Agile Development was great in understanding the many processes involved in producing good code works and how to work effectively in a team of programmers.

1 Like