#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.