Overclock.net › Forums › Software, Programming and Coding › Coding and Programming › Converter Program in Python - Could use a bit of help
New Posts  All Forums:Forum Nav:

Converter Program in Python - Could use a bit of help

post #1 of 7
Thread Starter 
I'm making a program that converts Feet to Meters and vise versa. I have a swap button that switches between the two conversions, but it isn't working correctly. If I start the program and type in a number, it successfully converts Feet to Meters, but when I hit the swap button, it doesn't change the conversion.

Likewise, if I start the program, click the Swap button, and type in a number, it successfully converts Meters to Feet, but when I Swap back to Feet to Meters it continues to convert Meters to Feet.

Code:
import Tkinter

win = Tkinter.Tk() # creates window
win.title("Converter") # title of window

Row1 = Tkinter.Label(win,text="Convert Feet To Meters", font=("Courier New",30)) #displays text "Convert to Meters" on Row1
Row1.pack() #calls .pack geometry manager

odd_even = 2

def swap_text():    
    if (odd_even % 2 == 0):
        feetLabel.config(text="Meters")
        metersLabel.config(text="Feet")
        global odd_even
        odd_even = odd_even + 1                       #switches placement of "Meters" and "Feet"
    else:                                             #switches conversion formula according to placement
        feetLabel.config(text="Feet")                 
        metersLabel.config(text="Meters")
        odd_even = odd_even + 1


Row2 = Tkinter.Frame(win)
feetLabel = Tkinter.Label(Row2,text="Feet",font=("Courier New",30))
feetEntry = Tkinter.Entry(Row2,width=6,font=("Courier New",30))
feetLabel.pack(side="left")
feetEntry.pack(side="left")
Row2.pack()

def convert_to_meters():
    st = feetEntry.get()                                
    v = eval(st)                                        
    if type(v) !=type("Hello"):
        valueLabel.config(text=str(v*.3048))

def convert_to_feet():
    st = feetEntry.get()
    v = eval(st)
    if type(v) !=type("Hello"):
        valueLabel.config(text=str(v+2))

def swap_convert():
    global odd_even
    if (odd_even % 2 == 0):
        cb.config(command=convert_to_meters)
        odd_even
    elif (odd_even % 2 != 0):
        cb.config(command=convert_to_feet)
        


Row3 = Tkinter.Frame(win) # creates fram to place things in
metersLabel = Tkinter.Label(Row3,text="Meters",font=("Courier New",30)) #displays the words "Meters" on Row3
valueLabel = Tkinter.Label(Row3,text="  ",font=("Courier New",30)) 
metersLabel.pack(side="left")
valueLabel.pack(side="left")
Row3.pack()


Row4 = Tkinter.Frame(win)
qb = Tkinter.Button(Row4,text="Quit",command=win.destroy,font=("Courier New", 30))  #quit button
cb = Tkinter.Button(Row4,text="Convert",command=swap_convert,font=("Courier New",30))    #convert button
sb = Tkinter.Button(Row4,text="Swap",command=swap_text,font=("Courier New",30))          #swap button
qb.pack(side="left")
cb.pack(side="left")
sb.pack(side="left")
Row4.pack()

win.mainloop()
SOOR
(15 items)
 
  
CPUMotherboardGraphicsRAM
FX 6300 Asrock 990FX Extreme3 MSI GTX 970 GAMING Ripjaws X 2x8GB 2133 
Hard DriveHard DriveOptical DriveCooling
Crucial MX100 Seagate Barracuda ST1000DM003 SAMSUNG DVD Burner 24X DVD+R 8X DVD+RW 8X DVD+R... Hyper 212 EVO 
OSMonitorMonitorKeyboard
Windows 10 x64 LG 27MP33HQ 1900x1080 IPS 27" HP 2009m 1600x900 Generic Dell Keyboard 
PowerCaseMouse
Corsair CX600 Corsair Carbide 500r Logitech B100 
  hide details  
Reply
SOOR
(15 items)
 
  
CPUMotherboardGraphicsRAM
FX 6300 Asrock 990FX Extreme3 MSI GTX 970 GAMING Ripjaws X 2x8GB 2133 
Hard DriveHard DriveOptical DriveCooling
Crucial MX100 Seagate Barracuda ST1000DM003 SAMSUNG DVD Burner 24X DVD+R 8X DVD+RW 8X DVD+R... Hyper 212 EVO 
OSMonitorMonitorKeyboard
Windows 10 x64 LG 27MP33HQ 1900x1080 IPS 27" HP 2009m 1600x900 Generic Dell Keyboard 
PowerCaseMouse
Corsair CX600 Corsair Carbide 500r Logitech B100 
  hide details  
Reply
post #2 of 7
Code:
cb = Tkinter.Button(Row4,text="Convert",command=swap_convert,font=("Courier New",30))    #convert button
Code:
def swap_convert():
    global odd_even
    if (odd_even % 2 == 0):
        cb.config(command=convert_to_meters)
        odd_even
    elif (odd_even % 2 != 0):
        cb.config(command=convert_to_feet)

The first time you click this button you change what it does.
Don't change what it does. Have it call your conversion functions.
Code:
def swap_convert():
    global odd_even
    if (odd_even % 2 == 0):
        convert_to_meters()
    elif (odd_even % 2 != 0):
        convert_to_feet()


Working with a few changes
Code:
import Tkinter

# creates window
win = Tkinter.Tk() 

# title of window
win.title("Converter") 

# displays text "Convert to Meters" on Row1
Row1 = Tkinter.Label(win,text="Convert Feet To Meters", font=("Courier New",15)) 

# calls .pack geometry manager
Row1.pack() 

odd_even = 2
v_feet_entry = Tkinter.StringVar()

def swap_text():    
    global odd_even
    
    # switches placement of "Meters" and "Feet"
    if (odd_even % 2 == 0):
        feetLabel.config(text="Meters")
        metersLabel.config(text="Feet")
        odd_even = 3
        v = float(valueLabel.cget("text"))
        v_feet_entry.set(str(v))
        valueLabel.config(text=str(v * .3048))
        convert_to_feet()
        
    # switches placement of "Feet" and "Meters"
    else:                                             
        feetLabel.config(text="Feet")                 
        metersLabel.config(text="Meters")
        odd_even = 2
        v = float(valueLabel.cget("text"))
        v_feet_entry.set(str(v))
        valueLabel.config(text=str(v / 0.3048))
        convert_to_meters()


Row2 = Tkinter.Frame(win)
feetLabel = Tkinter.Label(Row2,text="Feet",font=("Courier New",15))
feetEntry = Tkinter.Entry(Row2,width=6,font=("Courier New",15),textvariable=v_feet_entry)
feetLabel.pack(side="left")
feetEntry.pack(side="left")
Row2.pack()

def convert_to_meters():
    st = feetEntry.get()                                
    v = eval(st)                                        
    if type(v) !=type("Hello"):
        valueLabel.config(text=str(v * .3048))

def convert_to_feet():
    st = feetEntry.get()
    v = eval(st)
    if type(v) !=type("Hello"):
        valueLabel.config(text=str(v / .3048))

def swap_convert():
    # switches conversion formula accordingly
    global odd_even
    if (odd_even % 2 == 0):
        convert_to_meters()
    elif (odd_even % 2 != 0):
        convert_to_feet()


# creates fram to place things in
Row3 = Tkinter.Frame(win) 

# displays the words "Meters" on Row3
metersLabel = Tkinter.Label(Row3,text="Meters",font=("Courier New",15)) 
valueLabel = Tkinter.Label(Row3,text="  ",font=("Courier New",15)) 
metersLabel.pack(side="left")
valueLabel.pack(side="left")
Row3.pack()

Row4 = Tkinter.Frame(win)

# quit button
qb = Tkinter.Button(Row4,text="Quit",command=win.destroy,font=("Courier New", 15))       

# convert button
cb = Tkinter.Button(Row4,text="Convert",command=swap_convert,font=("Courier New",15))    

# swap button
sb = Tkinter.Button(Row4,text="Swap",command=swap_text,font=("Courier New",15))          

# pack buttons
qb.pack(side="left")
cb.pack(side="left")
sb.pack(side="left")
Row4.pack()

win.mainloop()
Core I7
(13 items)
 
  
CPUMotherboardGraphicsRAM
I7 920 rev. D0 @ 4.26Ghz EVGA X58 SLI EVGA GTX 285 OCZ XMP 3x2Gb (pc3 12800) 
Hard DriveOptical DriveOSMonitor
Western Digital Caviar Black 640Gb x 2 LG GH22LS30 openSuse 12.1 x64 HP F2105 
PowerCase
CORSAIR 850TX Cooler Master ATCS 840 
  hide details  
Reply
Core I7
(13 items)
 
  
CPUMotherboardGraphicsRAM
I7 920 rev. D0 @ 4.26Ghz EVGA X58 SLI EVGA GTX 285 OCZ XMP 3x2Gb (pc3 12800) 
Hard DriveOptical DriveOSMonitor
Western Digital Caviar Black 640Gb x 2 LG GH22LS30 openSuse 12.1 x64 HP F2105 
PowerCase
CORSAIR 850TX Cooler Master ATCS 840 
  hide details  
Reply
post #3 of 7
Some suggestions:

Don't use eval. Instead of typing in a number, try typing __import__("this") and see what happens. This won't mess up your computer, but other things people type might. Instead, convert the string directly to a float with float(st). This has the added benefit ensuring the result is a float so you don't have to do the type check step you did (and note that type(v) != type("Hello") can be shortened to type(v) != str).

You're using odd_even as a Boolean variable in a very roundabout way - just simply do odd_even = True or odd_even = False.

Don't use # to comment your functions. Instead, use docstrings.

It's really confusing that feetLabel can have the text "Meters", and the same is true for metersLabel. Instead, give them different names.

Don't use variable names like qb or win. Use more descriptive names. It doesn't matter now, but it will matter when you have 10,000 lines of code and you're trying to remember what in the world qb is.

You don't need to wrap the expression after the if and elif keywords in parentheses. Python doesn't use C-style syntax.

The most common Python convention is to use snake_case for variable and function names. If you really prefer camelCase at least be consistent and don't mix it up. Don't use capital letters to begin variable names - those are for classes.

If you have more time:


Read about exceptions. With this, you can handle invalid input.

Add an if __name__ == "__main__" statement. That way, if someone imports your module, it won't automatically run.

Add a shebang line.

Look up the grid layout manager in Tkinter. It will give you more control over how your program looks compared to pack.

Avoid using global variables. Usually there's a way around it. The way I would write this is to put everything in a class, with odd_even as an instance variable. But if you haven't gotten to classes yet don't worry too much about it.
Computer
(14 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i5-4430 Gigabyte GA-H81M-DS2V  MSI GTX 650 Ti Boost Twin Frozr 2 GB ADATA XPG V1.0 DDR3-1600 (2 x 4 GB) 
Hard DriveCoolingOSMonitor
OCZ Agility 3 120 GB and Seagate 7200.9 250 GB Cooler Master Hyper 212+ Windows 7 x64 ASUS VS239H-P 23" 
KeyboardPowerCaseMouse
Razer BlackWidow Antec Earthwatts 500w Cooler Master Elite 341 Microsoft IME 3.0 
  hide details  
Reply
Computer
(14 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i5-4430 Gigabyte GA-H81M-DS2V  MSI GTX 650 Ti Boost Twin Frozr 2 GB ADATA XPG V1.0 DDR3-1600 (2 x 4 GB) 
Hard DriveCoolingOSMonitor
OCZ Agility 3 120 GB and Seagate 7200.9 250 GB Cooler Master Hyper 212+ Windows 7 x64 ASUS VS239H-P 23" 
KeyboardPowerCaseMouse
Razer BlackWidow Antec Earthwatts 500w Cooler Master Elite 341 Microsoft IME 3.0 
  hide details  
Reply
post #4 of 7
Quote:
Originally Posted by aldfig0 View Post

Some suggestions:

Don't use eval. Instead of typing in a number, try typing __import__("this") and see what happens. This won't mess up your computer, but other things people type might. Instead, convert the string directly to a float with float(st). This has the added benefit ensuring the result is a float so you don't have to do the type check step you did (and note that type(v) != type("Hello") can be shortened to type(v) != str).

You're using odd_even as a Boolean variable in a very roundabout way - just simply do odd_even = True or odd_even = False.

Don't use # to comment your functions. Instead, use docstrings.

It's really confusing that feetLabel can have the text "Meters", and the same is true for metersLabel. Instead, give them different names.

Don't use variable names like qb or win. Use more descriptive names. It doesn't matter now, but it will matter when you have 10,000 lines of code and you're trying to remember what in the world qb is.

You don't need to wrap the expression after the if and elif keywords in parentheses. Python doesn't use C-style syntax.

The most common Python convention is to use snake_case for variable and function names. If you really prefer camelCase at least be consistent and don't mix it up. Don't use capital letters to begin variable names - those are for classes.

If you have more time:


Read about exceptions. With this, you can handle invalid input.

Add an if __name__ == "__main__" statement. That way, if someone imports your module, it won't automatically run.

Add a shebang line.

Look up the grid layout manager in Tkinter. It will give you more control over how your program looks compared to pack.

Avoid using global variables. Usually there's a way around it. The way I would write this is to put everything in a class, with odd_even as an instance variable. But if you haven't gotten to classes yet don't worry too much about it.

The only thing I agree with is the use of eval()
Everything else is opinion and not reverent, unless your are one of the PEP Police. Except for the use of exceptions, and only if you use them correctly.
The OP is learning, don't confuse logic with PEP. The PEP police are the one drawback to python
And a shebang is only reverent for Unix and Unix like OS's. Python is not an OS and a shebang has nothing to do with python. It only affects the OS and how you run the script, nothing more.
The layout manager is up to the one that is making the program, the place manager is more accrue and has more control then grid so why not mention that (pure opinion).
And why in the world would you think that someone would import this as a module, that is not something the OP has to worry about.

OOP is a ways down the road for the OP so the use of global variables is fine, acceptable, and the easiest way to do it. I would use a list if I didn't want to use a global, why make the code twice as long to do something simple. You're the one that said "import this"
Code:
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!

and it is "import this" not __import__("this")
Core I7
(13 items)
 
  
CPUMotherboardGraphicsRAM
I7 920 rev. D0 @ 4.26Ghz EVGA X58 SLI EVGA GTX 285 OCZ XMP 3x2Gb (pc3 12800) 
Hard DriveOptical DriveOSMonitor
Western Digital Caviar Black 640Gb x 2 LG GH22LS30 openSuse 12.1 x64 HP F2105 
PowerCase
CORSAIR 850TX Cooler Master ATCS 840 
  hide details  
Reply
Core I7
(13 items)
 
  
CPUMotherboardGraphicsRAM
I7 920 rev. D0 @ 4.26Ghz EVGA X58 SLI EVGA GTX 285 OCZ XMP 3x2Gb (pc3 12800) 
Hard DriveOptical DriveOSMonitor
Western Digital Caviar Black 640Gb x 2 LG GH22LS30 openSuse 12.1 x64 HP F2105 
PowerCase
CORSAIR 850TX Cooler Master ATCS 840 
  hide details  
Reply
post #5 of 7
First of all, maybe the reason why I posted that was unclear. I didn't post it because I thought what I wrote was necessary to just get the program running. Rather, I wanted to introduce the OP to common practices that manage complexity, increase portability, and ultimately minimize frustration later down the road - something to consider when writing Python programs.

These:
Quote:
The only thing I agree with is the use of eval()
Quote:
Except for the use of exceptions, and only if you use them correctly.
Quote:
OOP is a ways down the road for the OP so the use of global variables is fine, acceptable, and the easiest way to do it. I would use a list if I didn't want to use a global,
are not in contradiction with what I've said, so I'll move on. And this:
Quote:
why make the code twice as long to do something simple.
will be explained shortly. As you mostly likely know, a large portion of a programmer's time is spent quashing bugs and going "WHY IS IT DOING THAT??!?1!" Doing the things I pointed out will reduce these issues. I don't think my suggestions are excessive; in no part am I recommending doing this.

You are in a very small minority if you think uselessly named variables (like qb) or misleadingly named variables (feetLabel, which can contain meters) are acceptable. In fact, I'm having a hard time trying to come up with a response to this because I can't think of a single person that would defend this, and I strongly suspect you are aware of this. The only thing I can think of is that it is not pertinent to making the program functional, but that's not why I made my comment.

Coding standards exist for a reason - they make writing software, especially complex software, manageable. It allows for the principle of least astonishment. For example, if someone follows PEP 8, then when I see something that StartsWithCaps I already know a fact about it before I even did anything - it's a class. In contrast, I don't know what to expect with the OP's code - I can be surprised at every corner, and that just makes the code harder to read and more frustrating to maintain. Some coding standards add useful features to your code, that - you've guessed it - helps manage complexity.. For example, writing a docstring is objectively more useful than a plain comment - you can access your docstring by using the __doc__ magic method or the help function, whereas if you wrote a plain comment you'll have to find the module where the function was written, open up the module, and then find the function and see if there's a comment next to it. These little things add up, and make the difference between unmanageable spaghetti code and something that I would actually like to contribute to.

Shebang lines and if __name__ == "__main__" at worst don't do anything, and at best make the code you write a little more useful to someone else using your program and reduces unexpected behavior and bugs. That's reason enough to include them.

Finally, this:
Quote:
and it is "import this" not __import__("this")
...is just wrong. Fire up a Python interpreter and type eval("import this"). It won't work.
Edited by aldfig0 - 10/3/15 at 3:38am
Computer
(14 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i5-4430 Gigabyte GA-H81M-DS2V  MSI GTX 650 Ti Boost Twin Frozr 2 GB ADATA XPG V1.0 DDR3-1600 (2 x 4 GB) 
Hard DriveCoolingOSMonitor
OCZ Agility 3 120 GB and Seagate 7200.9 250 GB Cooler Master Hyper 212+ Windows 7 x64 ASUS VS239H-P 23" 
KeyboardPowerCaseMouse
Razer BlackWidow Antec Earthwatts 500w Cooler Master Elite 341 Microsoft IME 3.0 
  hide details  
Reply
Computer
(14 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i5-4430 Gigabyte GA-H81M-DS2V  MSI GTX 650 Ti Boost Twin Frozr 2 GB ADATA XPG V1.0 DDR3-1600 (2 x 4 GB) 
Hard DriveCoolingOSMonitor
OCZ Agility 3 120 GB and Seagate 7200.9 250 GB Cooler Master Hyper 212+ Windows 7 x64 ASUS VS239H-P 23" 
KeyboardPowerCaseMouse
Razer BlackWidow Antec Earthwatts 500w Cooler Master Elite 341 Microsoft IME 3.0 
  hide details  
Reply
post #6 of 7
Quote:
Originally Posted by aldfig0 View Post

Finally, this:
...is just wrong. Fire up a Python interpreter and type eval("import this"). It won't work.
Missed your point of use in my reading of this so sorry for that one, my error
Quote:
Originally Posted by aldfig0 View Post

Shebang lines and if __name__ == "__main__" at worst don't do anything, and at best make the code you write a little more useful to someone else using your program and reduces unexpected behavior and bugs. That's reason enough to include them.

That's reason enough to include them? What happened to the PEP. Keep it simple. A shebang can add problems in this case.
Which Shebang should OP use?
For Windows it doesn't matter, it will be ignored.
For Mac python2 is the default, unless someone installed python3, same for Linux
So #!/usr/bin/env python is going to cause problems if python3 is the default.
Example
What happens if you use that shebang on a fresh copy of Ubuntu? Ubuntu's popular and a lot of people use it
Code:
Traceback (most recent call last):
  File "cnv.py", line 3, in <module>
    import Tkinter
ImportError: No module named 'Tkinter'

Maybe if you set it to use python2
#!/usr/bin/env python2
/usr/bin/env: python2: No such file or directory

Again Ubuntu does not have python2 installed by default.
Code:
if __name__ == "__main__":

If you import this as a module (something it was not written as) how are you going to use it without making other changes.

Quote:
Originally Posted by aldfig0 View Post

You are in a very small minority if you think uselessly named variables (like qb) or misleadingly named variables (feetLabel, which can contain meters) are acceptable. In fact, I'm having a hard time trying to come up with a response to this because I can't think of a single person that would defend this, and I strongly suspect you are aware of this. The only thing I can think of is that it is not pertinent to making the program functional, but that's not why I made my comment.

Coding standards exist for a reason - they make writing software, especially complex software, manageable. It allows for the principle of least astonishment. For example, if someone follows PEP 8, then when I see something that StartsWithCaps I already know a fact about it before I even did anything - it's a class. In contrast, I don't know what to expect with the OP's code - I can be surprised at every corner, and that just makes the code harder to read and more frustrating to maintain. Some coding standards add useful features to your code, that - you've guessed it - helps manage complexity.. For example, writing a docstring is objectively more useful than a plain comment - you can access your docstring by using the __doc__ magic method or the help function, whereas if you wrote a plain comment you'll have to find the module where the function was written, open up the module, and then find the function and see if there's a comment next to it. These little things add up, and make the difference between unmanageable spaghetti code and something that I would actually like to contribute to.

Yes i must be in the minority because you never see things like this
Code:
def f(n):
    if n==1 or n==2:
        return 1
    return f(n - 1) + f(n - 2)

print f(25)

qb, cb, sb are easy enough to understand. quit button, change button, switch button so it's a moot point.
The others are not the greatest choices, but they are for the OP, not you or me. This is not production code, it's somebody learning to code. So again it does not matter.
And have you looked at the source code for python? The authors don't seem to have a problem using 2 letter variable names.

As for docstrings. Do you really need doc strings in this case? It's not "Production code" or a module, he/she will not be using sphinx on it, it's a standalone script to help the OP learn. The OP can learn about them later. Why make things more complicated then they need to be. For now the comments in the code are more then enough to get his/her point across and point out what they are doing, a well written docstring will not change that.
Core I7
(13 items)
 
  
CPUMotherboardGraphicsRAM
I7 920 rev. D0 @ 4.26Ghz EVGA X58 SLI EVGA GTX 285 OCZ XMP 3x2Gb (pc3 12800) 
Hard DriveOptical DriveOSMonitor
Western Digital Caviar Black 640Gb x 2 LG GH22LS30 openSuse 12.1 x64 HP F2105 
PowerCase
CORSAIR 850TX Cooler Master ATCS 840 
  hide details  
Reply
Core I7
(13 items)
 
  
CPUMotherboardGraphicsRAM
I7 920 rev. D0 @ 4.26Ghz EVGA X58 SLI EVGA GTX 285 OCZ XMP 3x2Gb (pc3 12800) 
Hard DriveOptical DriveOSMonitor
Western Digital Caviar Black 640Gb x 2 LG GH22LS30 openSuse 12.1 x64 HP F2105 
PowerCase
CORSAIR 850TX Cooler Master ATCS 840 
  hide details  
Reply
post #7 of 7
If you don't have Python 2 installed, then you can't even run the script in the first place, with or without the shebang line. I don't see the problem.

Variable names such as n, i, j, k, etc., are universally understood to represent integers or counter variables. There is no such precedent for qb, cb, and sb; their meanings are only obvious in hindsight. If you ask any random programmer what the variable n might represent without telling them any other information, they will most likely guess it's an integer of some sort. In contrast, a random programmer won't be able to guess what qb, cb, and sb might stand for. However, if you ask them what quit_button, change_button, and switch_button might represent, they'll likely guess that they're for some buttons in a GUI - no additional information needed. Generalizing from some select cases such as that in your Fibonacci example to show that such a practice is acceptable is an inductive fallacy.

This:
Quote:
This is not production code, it's somebody learning to code. So again it does not matter.
is probably where the bulk of the disagreement comes from. This is a terrible mentality to have. Allow me to illustrate: suppose that a beginner is learning about weightlifting. You don't say "oh you're just learning, you don't need proper form. It's only 10 pounds; you won't injure yourself." You start with proper form on day 1. Why? It stops bad habits from forming, causing serious problems later on when it really matters. A few seconds saved by being lazy with variable names and not bothering to type a few extra lines results in hours of frustration for others as they try to figure out what's going on with your spaghetti code. Following standards allows your code to be predictable and maintainable. If you stick with this from the beginning, you won't be inclined to the aforementioned bad habits.
Edited by aldfig0 - 10/3/15 at 11:17pm
Computer
(14 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i5-4430 Gigabyte GA-H81M-DS2V  MSI GTX 650 Ti Boost Twin Frozr 2 GB ADATA XPG V1.0 DDR3-1600 (2 x 4 GB) 
Hard DriveCoolingOSMonitor
OCZ Agility 3 120 GB and Seagate 7200.9 250 GB Cooler Master Hyper 212+ Windows 7 x64 ASUS VS239H-P 23" 
KeyboardPowerCaseMouse
Razer BlackWidow Antec Earthwatts 500w Cooler Master Elite 341 Microsoft IME 3.0 
  hide details  
Reply
Computer
(14 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i5-4430 Gigabyte GA-H81M-DS2V  MSI GTX 650 Ti Boost Twin Frozr 2 GB ADATA XPG V1.0 DDR3-1600 (2 x 4 GB) 
Hard DriveCoolingOSMonitor
OCZ Agility 3 120 GB and Seagate 7200.9 250 GB Cooler Master Hyper 212+ Windows 7 x64 ASUS VS239H-P 23" 
KeyboardPowerCaseMouse
Razer BlackWidow Antec Earthwatts 500w Cooler Master Elite 341 Microsoft IME 3.0 
  hide details  
Reply
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Coding and Programming
Overclock.net › Forums › Software, Programming and Coding › Coding and Programming › Converter Program in Python - Could use a bit of help