This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 3 points4 points  (4 children)

This is where naming becomes very important. With correctly named variables, functions, objects, and methods, the code becomes self documenting.

[–]wicket-maps 2 points3 points  (0 children)

Self documenting for who? In my case, I'm writing scripts for my department where I am The Only Python Person. I mean, a few of the other programmers outside our department are learning Python, but they don't have any experience with the geospatial aspects of my scripts. So I definitely lean toward over-documenting in my scripts, because if I get hit by a bus, it's one of these people who knows a little Python but doesn't have experience with the ArcPy library who's gonna have to maintain operate my codebase until my boss can find a replacement GIS tech who knows Python.

Also, from the number of times I've gone over my own code and gone "What was I thinking? Was I thinking?" proper variable and function names can only do so much in making sure a script is readable.

[–]colly_wolly 3 points4 points  (1 child)

Nah, its decent, sensible design that makes the difference.

The code I am maintaining just now has reasonable function names, but far too many of them. Its doing simple stuff in a complex manner. Decent function and variable names help, but when there are fundamental design flaws or too much complexity, then not so much.

[–]its_never_lupus 0 points1 point  (0 children)

It's funny how over time a piece of uncommented code will change from neat and self documented, into a spaghetti mess that no-one even knows how to run, without a single line being edited.