Module 1: Python Environments and Flowcharts-Convert Radians to Degrees Pseudocode

To kickoff the first module for GIS5103-GIS Programming, the first task was to create a flowchart to visualize the process of a simple python script. The assigned task was to show the process of converting 3 radians to degrees and then to print the result. Flowchart shapes followed the pseudocode and flowcharts guidelines set by Agarwal et al. (2010). The final flowchart is included below: 

First, the starting point is noted as an oval. Then, all the the variables are defined as rectangles. In this scenario, we are converting 3 radians to degrees, so the first rectangle shows that radians = 3. Then, the second variable, pi, is defined as 3.14. The third rectangle is the equation to be used to convert from radians to degrees, which is degrees = radians*180/pi. Once all the variables and the equation is defined, the script would be initiated by doing the command print degrees, which would provide the calculated output. This command is shown in a parallelogram in the flowchart. Finally, the end oval indicates the end of the process. The use of flowcharts is a simpler way to be introduced to how Python programming works and is a great tool to plan how to write python scripts. 

The second part of the assignment was to review "The Zen of Python" by Tim Peters. A printout of the poem is below: 

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

The "Zen of Python" is a list of guidelines to writing python, in that it gives advice on working through the

best way to write a script. It advises that “beautiful”, “simple”, and “sparse” scripts are preferred over “complicated”, “nested”, “unreadable” scripts. Therefore, scripts should be a simple as possible but still get the job done. “Refuse the temptation to guess” says that everything should be defined and explicit, with nothing implied so that the script runs correctly. The line “If implementation is hard to explain, it's a bad idea” helps when trying to decide if an idea is realistic and can be done simply, which recalls the previous lines that “simple is better than complex” and “there should be one-- and preferably only one --obvious way to do it.” If the solution is not obvious or easy to explain, then the script is likely not going to be efficient and other alternatives may exist that are simpler. By following the guidelines, a person can create more efficient scripts.