[Top][All Lists]

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

[task #13658] Work on concave polygons too

From: Mohammad Akhlaghi
Subject: [task #13658] Work on concave polygons too
Date: Thu, 9 Apr 2020 12:57:33 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0

Update of task #13658 (project gnuastro):

                  Status:               Postponed => Done                   
        Percent Complete:                     70% => 100%                   
             Open/Closed:                    Open => Closed                 


Follow-up Comment #48:

Thanks a lot Sachin, it has been merged and pushed
<> to
the main branch :-D. 

Just some tips for the future (which I have implemented in the next commit

* In the documentation, when you define a function, put name of the argument
variables in a `@code{}'.

* When printing a warning in the programs, check if the `--quiet' option has
been called by the user. This is part of the common options
and in the code, its in the structure `gal_options_common_params' (which is
defined in lib/gnuastro-internal/options.h
In all the programs this structure is in `p->cp', so you can check the
`--quiet' option with `p->cp.quiet'.

* The precedence
<> of operators
like `&&' and `?:' are very low in the C language, so there is no need to use
parenthesis when they are placed between comparison operators like `<' or
`=='. Parenthesis (like brackets) should only be used when the precedence is
different from the C standard. An extra parenthesis will just make the
code-reader wonder why you used them? For example, they are going to ask
themselvs: Did you intend to do something else and forgot? is it a bug? The
Parenthesis I have added at the start and and end of the return statements of
`polygon_compareA' and `polygon_compareB' are to help in automatic formatting
of the code when it is broken up in multiple lines. Usually as soon as the
`?:' statement gets a little complex, its much more easier to read if you
break it into multiple lines like these two functions.

* Try to set descriptive names for your arguments and avoid using something
like `in' or `input', because they are very vague. For example in the case of
`gal_polygon_vertices_sort', I have changed the first argument to be
`vertices' instead of `in'. Its a form of documentation, and also makes it
easier to search for the instances of the variable in the code. It also helps
in actually writing the description of the function in the book ;-).


Reply to this item at:


  Message sent via Savannah

reply via email to

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