#133: Use consistent naming convention (w.r.t. underscores, abbreviations, etc.) -----------------------+---------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: defect | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Resolution: | Keywords: name coding style -----------------------+---------------------------------------------------- Old description:

We should write down __rules__ about names. For the moment, wiki:Olena/Release1.0beta#NamingconventionsforOlena1.0 seems to be a good place to write them. We might want to push them into the (developer) documentation later.

This ticket is a (relatively) unordered list of spotted issues. Decide, reorder and fix. Don't close this ticket too soon, and use it a as memo.

= Types (underscores, names) =

We adopted many silent conventions while developing the project, and inconsistencies arose. Here is a (non comprehensive) list of things to fix: * In source:trunk/mln/core/ `mln::window` vs `mln::neighb_` (full name vs short name + no trailing underscore vs trailing underscore) * Likewise, we have `mln::window` (without « `_` ») but `mln::point_`, etc. * In source:/trunk/milena/mln/accu/median.hh the class does not have any trailing underscore, whereas other accumulators from source:/trunk/milena/mln/accu/ have one. * graph- and complex-related domain-iterators have trailing underscores, whereas their vicinity counterparts does not.

= Traits macros =

* Should we use `mln_sum(V)` or `mln_trait_value_sum(V)` in the library code? I (Roland) think so.

= Neighborhoods =

* The terms/prefixes `nbh`, `neighb` and `neighborhood` are used inconsistently throughout the project. Here are the files that should be checked (and possibly renamed), as of revision r1859: * source:trunk/milena/mln/core/clock_neighb.hh * source:trunk/milena/mln/core/clock_neighb2d.hh * source:trunk/milena/mln/core/concept/doc/neighborhood.hh * source:trunk/milena/mln/core/concept/neighborhood.hh * source:trunk/milena/mln/core/graph_elt_neighborhood.hh * source:trunk/milena/mln/core/graph_neighborhood_piter.hh * source:trunk/milena/mln/core/line_graph_elt_neighborhood.hh * source:trunk/milena/mln/core/line_graph_neighborhood_piter.hh * source:trunk/milena/mln/core/neighb.hh * source:trunk/milena/mln/core/neighb1d.hh * source:trunk/milena/mln/core/neighb2d.hh * source:trunk/milena/mln/core/neighb3d.hh * source:trunk/milena/mln/metal/has_neighborhood.hh * source:trunk/milena/mln/neighb/ * source:trunk/milena/mln/trait/neighborhood.hh

New description: We should write down __rules__ about names. For the moment, wiki:Olena/Release1.0#NamingconventionsforOlena1.0 seems to be a good place to write them. We might want to push them into the (developer) documentation later. This ticket is a (relatively) unordered list of spotted issues. Decide, reorder and fix. Don't close this ticket too soon, and use it a as memo. = Types (underscores, names) = We adopted many silent conventions while developing the project, and inconsistencies arose. Here is a (non comprehensive) list of things to fix: * In source:trunk/mln/core/ `mln::window` vs `mln::neighb_` (full name vs short name + no trailing underscore vs trailing underscore) * Likewise, we have `mln::window` (without « `_` ») but `mln::point_`, etc. * In source:/trunk/milena/mln/accu/median.hh the class does not have any trailing underscore, whereas other accumulators from source:/trunk/milena/mln/accu/ have one. * graph- and complex-related domain-iterators have trailing underscores, whereas their vicinity counterparts does not. = Traits macros = * Should we use `mln_sum(V)` or `mln_trait_value_sum(V)` in the library code? I (Roland) think so. = Neighborhoods = * The terms/prefixes `nbh`, `neighb` and `neighborhood` are used inconsistently throughout the project. Here are the files that should be checked (and possibly renamed), as of revision r1859: * source:trunk/milena/mln/core/clock_neighb.hh * source:trunk/milena/mln/core/clock_neighb2d.hh * source:trunk/milena/mln/core/concept/doc/neighborhood.hh * source:trunk/milena/mln/core/concept/neighborhood.hh * source:trunk/milena/mln/core/graph_elt_neighborhood.hh * source:trunk/milena/mln/core/graph_neighborhood_piter.hh * source:trunk/milena/mln/core/line_graph_elt_neighborhood.hh * source:trunk/milena/mln/core/line_graph_neighborhood_piter.hh * source:trunk/milena/mln/core/neighb.hh * source:trunk/milena/mln/core/neighb1d.hh * source:trunk/milena/mln/core/neighb2d.hh * source:trunk/milena/mln/core/neighb3d.hh * source:trunk/milena/mln/metal/has_neighborhood.hh * source:trunk/milena/mln/neighb/ * source:trunk/milena/mln/trait/neighborhood.hh Comment (by levill_r): s|Olena/Release1.0beta|Olena/Release1.0|. -- Ticket URL: <https://trac.lrde.org/olena/ticket/133#comment:2> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.