[webkit-efl] Coding style issue in EFL port
tonikitoo at gmail.com
Thu Sep 15 06:48:20 PDT 2011
I don't want to commit lots of coding style patches as well. I think we need
> to ask *webkit-dev* how to commit this changes
> after finding proper solution. Recently, it seems to me Leandro asked the
> webkit-dev similar question ("committing EFL baselines").
History is important , but I am sure the benefit EFL would get by not scare
reviewers with a very
different coding style is bigger in this case.
> In my opinion, there are two issues. One is to use C-style despite file
> format is C++. The other is conflicts between
> efl coding style and webkit coding style.
> 1. efl style pointer operator coding style.
> : pointer('*') operator coding style follows efl coding style. It looks
> we need to adhere webkit coding style.
> 2. Should we use EINA_TRUE and EINA_FALSE?
> : It can be replace with true / false.
> 3. Internal functions are using '(void)' parameter.
> : As we already discussed, internal function needs to use C++ coding
> 4. Manual memory management.
> : ewk_xxx files are using malloc, calloc and realloc instead of smart
> For example, GOwnPtr.
> 5. C style casting operator.
> : Though file format is .cpp, some codes are still using c type casting
> 6. Meaningless parameter name.
> : We have used coding style of efl parameter so far. However, that is not
> webkit coding style.
> I heard that port implementation tends to be platform coding style.
> So, I added a parameter coding style exception to
> style checker for efl port. But, now I'm not sure whether we're able
> to use it continually.
That would be it, iirc. Some of them are very straightforward to fix, so I
would start with those right away, and getting the
pending review patches rebased. Also keep doing informal review on your
patches as you are atm. When it is ready for
prime time review, speak up, get someone on IRC, and voala.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-efl