Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   general coding issues - coding style... (http://www.velocityreviews.com/forums/t354573-general-coding-issues-coding-style.html)

calmar 02-18-2006 01:37 PM

general coding issues - coding style...
 
Hi all,

since I'm just a 'handicraft'/beginner or so,

could anybody provide me with some (rough) hints, about how to enhance the code
here:

http://calmar.ws/tmp/cal.html

Cheers and thanks a lot
calmar


--
calmar

(o_ It rocks: LINUX + Command-Line-Interface
//\
V_/_ http://www.calmar.ws

Diez B. Roggisch 02-18-2006 02:18 PM

Re: general coding issues - coding style...
 
calmar schrieb:
> Hi all,
>
> since I'm just a 'handicraft'/beginner or so,
>
> could anybody provide me with some (rough) hints, about how to enhance the code
> here:


- why are these {{{ thingies there?

- use string interpolation like "Foo %s %i" % ("bar", 1) instead of
concatenating strings.

- it seems that you could benefit from a class instead of a bunch of
functions & few globals. No need to go too crazy about OO, but it has
its merits

- try using something like glade - creating GUIs by hand sucks
big-timer :)

- read up about unicode and encodings, what they mean and why and when
to use what. Really. Most problems in that field stem from people being
sort of ignorant on that topic and just wiggling themselves through all
the time - in the end, messing up stuff. It really _isn't_ that complicated.

- when creating string-keyed dicts, the idiom

dict(foo="bar",
baz="pillepalle")

has its merits.

Besides that - looks ok to me.

Diez

calmar 02-18-2006 05:17 PM

Re: general coding issues - coding style...
 
On 2006-02-18, Diez B. Roggisch <deets@nospam.web.de> wrote:

Hi Diez,

> - why are these {{{ thingies there?


markers for folding for vim
http://www.calmar.ws/tmp/sc.png

> - use string interpolation like "Foo %s %i" % ("bar", 1) instead of
> concatenating strings.


I see, get's shorter and so, and I can break lines.
(seems to me, after ( or [ or so, I can use a new line without
to worry)

> - it seems that you could benefit from a class instead of a bunch of
> functions & few globals. No need to go too crazy about OO, but it has
> its merits


I see. Maybe I could then build some classes for that prog,
especially since I use only one file, it probably would make
some sense for getting a better structure.

>
> - try using something like glade - creating GUIs by hand sucks
> big-timer :)


I should (seriously) check out probably.

> - read up about unicode and encodings, what they mean and why and when
> to use what. Really. Most problems in that field stem from people being
> sort of ignorant on that topic and just wiggling themselves through all
> the time - in the end, messing up stuff. It really _isn't_ that complicated.


I read up. In fact, basically it does not seem to be that complicate.
Unicode just a 'numbered' list of all available character, and
e.g. uft-8 a organized way to 'store' those 'numbers' wisely
into bytes.

I still have some problems with that (and gave up), but since I begin to
now understand it somebit more, I should try/check again.

> - when creating string-keyed dicts, the idiom
>
> dict(foo="bar",
> baz="pillepalle")


I see, I changed too.

Thanks a lot,
marco

--
calmar

(o_ It rocks: LINUX + Command-Line-Interface
//\
V_/_ http://www.calmar.ws

plahey@alumni.caltech.edu 02-18-2006 11:29 PM

Re: general coding issues - coding style...
 
Hi,

1585 if sys.path[0][-12:] == "\library.zip": #for py2exe

how about

if sys.path[0].endswith( "\\library.zip" ):

(did you really mean one back-slash there?)


499 tuple = os.path.split(filename)

bad variable name... tuple(x) converts a sequence to a tuple.


You have a number of places where you check for len(x)==0:

674 if len(files) == 0:
853 if len(file_show) == 0:
950 if len(imgprocess["files_todo"]) == 0:

people usually recommend:

if not files:
if not file_show:
if not imgprocess["files_todo"]:


you should run your code through pychecker (it had a lot to say...).


You use global alot... that should be a red flag. Like the poster
above mentioned, you have things that are telling you they want to
be objects.


The #{{{ and #}}} stuff is very annoying to other programmers
(ok, to me...). You might want to investigate a Python aware
editor (like SPE, which has pychecker built in). This is
coming from someone who uses vim regularly.


Dylan Moreland 02-18-2006 11:35 PM

Re: general coding issues - coding style...
 

calmar wrote:
> On 2006-02-18, Diez B. Roggisch <deets@nospam.web.de> wrote:
> > - why are these {{{ thingies there?

>
> markers for folding for vim
> http://www.calmar.ws/tmp/sc.png


I would look into one of the many Vim scripts which automatically fold
most large blocks without the ugly {{{.


Justin Azoff 02-18-2006 11:50 PM

Re: general coding issues - coding style...
 
Dylan Moreland wrote:
> I would look into one of the many Vim scripts which automatically fold
> most large blocks without the ugly {{{.


Who needs a script?
"set foldmethod=indent"
works pretty well for most python programs.


calmar 02-19-2006 11:29 AM

Re: general coding issues - coding style...
 
On 2006-02-18, Justin Azoff <justin.azoff@gmail.com> wrote:

Hi all,

> Dylan Moreland wrote:
>> I would look into one of the many Vim scripts which automatically fold
>> most large blocks without the ugly {{{.

>
> Who needs a script?
> "set foldmethod=indent"
> works pretty well for most python programs.
>


Well, foldmethod=marker does not bother me, because the folds are
normally closed. With markers, it takes one line per function, with
indent I see 2, so I prefer markers.

...and since I can easily get rid of them, and add them again, I will at
least remove them before e.g. putting to the web or so.


Cheers and thanks,
calmar



--
calmar

(o_ It rocks: LINUX + Command-Line-Interface
//\
V_/_ http://www.calmar.ws

calmar 02-19-2006 12:24 PM

Re: general coding issues - coding style...
 
On 2006-02-18, plahey@alumni.caltech.edu <plahey@alumni.caltech.edu> wrote:

Hi,

> 1585 if sys.path[0][-12:] == "\library.zip": #for py2exe
> if sys.path[0].endswith( "\\library.zip" ):


cool, thx,

> (did you really mean one back-slash there?)


(yeah, one backslash)

> 499 tuple = os.path.split(filename)
> bad variable name... tuple(x) converts a sequence to a tuple.


I see, I changed that to
path, filen = os.path.split(filename)

> You have a number of places where you check for len(x)==0:
> 674 if len(files) == 0:
> --> if not files:


I see. thx

> you should run your code through pychecker (it had a lot to say...).


I see, cool tool that pychecker!
I can't do something against the 'not used variable' so probably?
(since pygtk just sends those items anyway)

> You use global alot... that should be a red flag. Like the poster
> above mentioned, you have things that are telling you they want to
> be objects.


I will try to get some order (classes) and maybe remove them.

thanks a lot!!

cheers,
calmar

--
calmar

(o_ It rocks: LINUX + Command-Line-Interface
//\
V_/_ http://www.calmar.ws

Bruno Desthuilliers 02-19-2006 10:06 PM

Re: general coding issues - coding style...
 
calmar a écrit :
> Hi all,
>
> since I'm just a 'handicraft'/beginner or so,
>
> could anybody provide me with some (rough) hints, about how to enhance the code
> here:
>
> http://calmar.ws/tmp/cal.html


1/ learn OO and get rid of globals.
2/ use dict or list based dispatch instead of long if/elif/elif... clauses
3/ stdout is meant for *normal* program outputs. Errors and verbosity go
to stderr
4/ triple quoted strings are fine for multiline text
5/ os.path is fine for portable filepath operations
6/ things that dont change during program execution (ie : constants)
should not be defined inside a function



> Cheers and thanks a lot
> calmar
>
>


calmar 02-20-2006 01:46 PM

Re: general coding issues - coding style...
 
On 2006-02-19, Bruno Desthuilliers <bdesth.quelquechose@free.quelquepart.fr> wrote:

Bonjour,

>
> 1/ learn OO and get rid of globals.


Well I created two classes now. I put some things global (your point 6).
e.g. if it's on Windows or not, and other things.

> 2/ use dict or list based dispatch instead of long if/elif/elif... clauses


when I find out what you mean, I will. Probably something lika a 'case'
thing? #python meant a list containing functions or so. So that the
values represent the functions to call, isn 'it?

> 3/ stdout is meant for *normal* program outputs. Errors and verbosity go
> to stderr


yeah, changed (somebit)

> 4/ triple quoted strings are fine for multiline text


yeah. I have lot of triple prints...

> 5/ os.path is fine for portable filepath operations


I don't really understant what you mean here, sorry

> 6/ things that dont change during program execution (ie : constants)
> should not be defined inside a function


As I mentioned above, these I placed globally:

main gtkwindows,
smwin or not,
pyexe or not,
preferred encoging

according to your statement?


Anyway, since I did lot of changes, I'm myself confused actually.
http://calmar.ws/tmp/cal.html

Will try to cleanup and implement even further all good
advices from all in some days.

Thanks a lot!!
calmar



--
calmar

(o_ It rocks: LINUX + Command-Line-Interface
//\
V_/_ http://www.calmar.ws


All times are GMT. The time now is 07:33 AM.

Powered by vBulletin®. Copyright ©2000 - 2013, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57