[Numpy-discussion] Github migration?

Benjamin Root ben.root@ou....
Thu Sep 2 12:22:30 CDT 2010


On Thu, Sep 2, 2010 at 12:11 PM, Charles R Harris <charlesr.harris@gmail.com
> wrote:

>
>
> On Thu, Sep 2, 2010 at 10:55 AM, Jason McCampbell <
> jmccampbell@enthought.com> wrote:
>
>>
>>
>> On Thu, Sep 2, 2010 at 10:25 AM, Charles R Harris <
>> charlesr.harris@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Sep 2, 2010 at 8:51 AM, Jason McCampbell <
>>> jmccampbell@enthought.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Sep 1, 2010 at 9:07 PM, Charles R Harris <
>>>> charlesr.harris@gmail.com> wrote:
>>>>
>>>>>
>>>>> Hi Jason,
>>>>>
>>>>> On Tue, Aug 31, 2010 at 2:56 PM, Jason McCampbell <
>>>>> jmccampbell@enthought.com> wrote:
>>>>>
>>>>>> Hi Chuck (and anyone else interested),
>>>>>>
>>>>>> I updated the refactoring page on the NumPy developer wiki (seems to
>>>>>> be down or I'd paste in the link).  It certainly isn't complete, but there
>>>>>> are a lot more details about the data structures and memory handling and an
>>>>>> outline of some additional topics that needs to be filled in.
>>>>>>
>>>>>>
>>>>> I note that there are some C++ style comments in the code which will
>>>>> cause errors on some platforms, so I hope you are planning on removing them
>>>>> at some point. Also,
>>>>>
>>>>
>>>> Mostly the C++ comments are there for specific things we need to fix
>>>> before it's complete (easier to search for).  Likely a few are attributable
>>>> to "muscle memory" in my fingers as well, but all will be removed as we
>>>> button it up.
>>>>
>>>>
>>>>>
>>>>> if (yes) foo;
>>>>>
>>>>> is very bad style. There is a lot of that in old code like that that
>>>>> still needs to be cleaned up, but I also see some in the new code. It would
>>>>> be best to get it right to start with.
>>>>>
>>>>
>>>> Agreed.  In the code I have edited I typically re-write it as "if (NULL
>>>> != yes) foo;" but a lot of code has been copied in wholesale and we haven't
>>>> always updated that code.
>>>>
>>>>
>>>
>>> I mean it is bad style to have foo on the same line as the if. I think
>>> this happens because folks start off wanting to save a bit of vertical space
>>> and a couple of keystrokes, but in the long run it tends to make the code
>>> harder to read.
>>>
>>
>> Oh, that's interesting.  I don't generally have an objection to 'foo' on
>> the same line for simple statement as, like you said, it saves a lot of
>> vertical space and the lack of curly's is more of an issue with:
>>     if (yes)
>>        foo;
>>
>>
> It's pretty universally a no-no, you won't find many (if any) style guides
> that permit it. Where they do differ is whether a single statement needs the
> curly braces and even there, if one block has multiple statements requiring
> the curlies, then all blocks get them. I think curly braces for all the
> blocks is reasonable as it adds a bit more regularity to the style. In any
> case, if you adhere to this standard I won't have to spend time fixing
> things up after you commit to mainline.
>
> Another no-no that I haven't noticed yet is to put more than one statement
> on a line.
>
>
>
>> I try to avoid the C-ism of default conversion of pointers to a bool
>> comparison.
>>
>>
> Yeah, that too ;)
>
> Chuck
>
>
I don't know if you guys are familiar with 'indent'?  I use it a lot to
convert code that I get from other people into a style that I personally
like.  It was specifically designed for C, but it can handle C++ code.  It
can do things like force curly braces, or make all single statement
ifs/while/for blocks be curly-less.  It can enforce line widths and break up
comments accordingly.  I bet it can even convert C++ style comments into C
style.  The man page is quite long with many options to choose from.

I have come across some other programs that were like 'indent' but designed
for C++, but I can not remember the name of them.

Ben Root
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20100902/3eb4f74e/attachment-0001.html 


More information about the NumPy-Discussion mailing list