[webkit-efl] Coding style issue in EFL port

[Antonio Gomes]

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
> style.
>
> 4. Manual memory management.
>   : ewk_xxx files are using malloc, calloc and realloc instead of smart
> pointer.
>      For example, GOwnPtr.
>
> 5. C style casting operator.
>   : Though file format is .cpp, some codes are still using c type casting
> operator.
>
> 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.


-- 
--Antonio Gomes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-efl/attachments/20110915/34d41358/attachment.html>