[webkit-efl] Coding style issue in EFL port

[Gyuyoung Kim]

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

 

If you think so, I will file bugs for this issue. And also, I think it is
better to file a meta bug, which maintains issues listed.

 

Hello Kubo, do you agree with my suggestion ?

 

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

 

Yes, I agree with your advice. We need to solve this issue ASAP. Then, the
pending patches also should follow this rule. They may need to be rebased. 

 

- Gyuyoung

 

From: Antonio Gomes [mailto:tonikitoo at gmail.com] 
Sent: Thursday, September 15, 2011 10:48 PM
To: Gyuyoung Kim
Cc: Raphael Kubo da Costa; webkit-efl at lists.webkit.org; tkent at chromium.org;
Eric Seidel; kenneth at webkit.org
Subject: Re: [webkit-efl] Coding style issue in EFL port

 

 

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/20110916/2f4c13eb/attachment-0001.html>