dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]dir.c


From: Gopal V
Subject: Re: [DotGNU]dir.c
Date: Fri, 25 Oct 2002 04:39:33 +0530
User-agent: Mutt/1.2.5i

If memory serves me right, Charles Shuller wrote:
> about the differences in coding styles, that are best asked in the code 
> where you can see whats going on more easily.  

good , I find it easier to answer direct questions ... :-)
> /*
>  * public static Errno GetFilesInDirectory(String path, out 
>  *                                                                            
>         Platform.FileInfo[] files);
>  */
> /*  What is with the funky break?  */

Just to make it wrap into the small screen I have here ... I think
moving the args into the next line is a good idea, to make it clearer
I have added the tabs to show that it is an arg of GetFilesInDirectory.
Just a vestige from my coding style which has migrated into comments..

>       ILDir *dirStream; /* follow a single std of naming */

viz no dir_stream or dirstream ... use dirStream like case for all vars.
the fooBar model is used throught out pnet (AFAIK)...

<rhysw>:Field, parameter and local variable names begin with lower case.

>       Platform_FileInfo *buffer=NULL; /*coz _ptr is for fools who forget :-) 
> */
>    /*  Oh, Shush, it is also helpfull for people starting in the middle
>        or for those who are new to C, but I have no prob leaving it out 
>        for stylistic reasons :) */

Hehe .... I just put it there as a joke about "buffer_ptr_ptr" or 
something like that ... the "_" char is not one of rhys's favourite
keys (RSI ?) ..

>       ILInt32 i;  /*  How surprising, an index var named 'i' */
>       /*  I thought this was generaly accepted practice, */

Hell no !! ... I usually spruce up my code with comments so that the
programmer reading it again has a good laugh .. like:

||      blob=(void*)ILAttributeGetValue(attr,&len); 
||      /* keep blob for cooking later */

> #ifdef HAVE_DIRENT_H /* the dirent-> is included only if HAVE_DIRENT_H */
>                    /*  Sortof, Win32 has a different method of this type
>                        of operation, so when ported it will also be typedefed
>                        to ILDir.  I'll leave the ifdef in for you to decide.  
> */

what I meant was that eventhough ILDir will be typedef'd , the new type for
ILDir might not have an ILDir->d_name in it ... so this code is ifdef'd 
as HAVE_DIRENT_H ... Member access functions into such opaque or variable
(as in compile time) types should be appropriately #ifdef'd .. or it 
causes a number of compiler errors...

>       *files = (System_Array*) ILExecThreadNew(_thread,
>                                               
> "[vPlatform.FileInfo;","(Ti)V",(ILVaInt)(arraySize));
>       /* I'm confused as to why the linebreak here and with this much 
> tabbing.  
>      Is there a specific colum we don't want to pass?  */

column 80, which is the limit for my command line editor (--no editor wars 
please --) ... Which I assume is the same for Rhys as well ...

and the tabbing is just a habit I got from autoindent .. (so you guessed, I
use vim) .. try "set autoindent" and moving an arg to the next line .. It
automatically tabsets it to a few tabs right...

>       /*  Also, am I not allowed to double space between signifigant blocks 
> of code?  */
>       if(!(*files))

Hmm.. well only if one of those lines are a comment ;-) ... that is no
stylistic blunder , it was just that I thought the if was part of the
allocation as well in my C-processing section of the brain ..

>               /*  Is it stylistically wrong to space before break, and even
>                   put it in '{' '}' ???  */
>               if(!dirEntry)break;

nope ... that was *my* mistake ... I just saved a couple of lines 
of typing with that ... don't try to think too much about these *small*
issues ... well you're welcome to write that as 

if(!dirEntry) break;

or 

if(!dirEntry) 
{
        break;
}

The last being the most stylistically *correct* ... :-) But don't
worry about the small stuff here ..

The biggies are the variable/function names, position of braces, 
line wrapping (80) and tabspaces....

> cleanup:

So that we can deallocate memory or send back an empty array ... viz
equivalent of "I've had an error, bailing out" method..

Btw, read http://mindprod.com/unmain.html for more (mis)information..

Gopal
-- 
The difference between insanity and genius is measured by success


reply via email to

[Prev in Thread] Current Thread [Next in Thread]