[task #13658] Work on concave polygons too

[Mohammad Akhlaghi]

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
<http://git.savannah.gnu.org/cgit/gnuastro.git/commit/?id=debef79f94c5f0a2> to
the main branch :-D. 

Just some tips for the future (which I have implemented in the next commit
<http://git.savannah.gnu.org/cgit/gnuastro.git/commit/?id=24ccb251cdb5>):

* 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
<https://www.gnu.org/software/gnuastro/manual/html_node/Operating-mode-options.html>,
and in the code, its in the structure `gal_options_common_params' (which is
defined in lib/gnuastro-internal/options.h
<http://git.savannah.gnu.org/cgit/gnuastro.git/tree/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
<https://en.cppreference.com/w/c/language/operator_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:

  <https://savannah.gnu.org/task/?13658>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/