[webkit-efl] Coding style issue in EFL port

[Gyuyoung Kim]

(I'm also keeping the CC'ed guys on this CC list because I'd like to let
related reviewers know this effort.
 If you guys don't want to add CC list, feel free to let us know. We will
remove you from the CC list.)

Hello Kubo,

Thank you for your advice first.

> I am all for consistency too. My main concern with committing lots of
> coding style patches is that it makes history tracking (svn blame and
> friends) difficult.

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


>> This does not mean that the benefits might not outweight the costs, but
>> before sending any patch to Bugzilla it would be good if you came with a
>> more detailed proposal of what you want to do and where (and/or a coding
>> style proposal for Source/WebKit/efl).

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.

Although I don't find all issues in efl port yet, I list issues I found up
for now,

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.

If anyone has any comments related to above issues, feel free to reply this
email.

- Gyuyoung

> -----Original Message-----
> From: webkit-efl-bounces at lists.webkit.org [mailto:webkit-efl-
> bounces at lists.webkit.org] On Behalf Of Raphael Kubo da Costa
> Sent: Wednesday, September 14, 2011 10:49 PM
> To: webkit-efl at lists.webkit.org
> Cc: tkent at chromium.org; 'Eric Seidel'; tonikitoo at webkit.org;
> kenneth at webkit.org
> Subject: Re: [webkit-efl] Coding style issue in EFL port
> 
> (For now I'm keeping the CC'ed guys on the CC list, but feel free to
> shout out loud so we can remove you from it if you prefer)
> 
> Gyuyoung Kim <gyuyoung.kim at samsung.com> writes:
> 
> > If nobody oppose my opinion, I'd like to file bugs for this issue, then
> I
> > prepare patches for that bugs.
> > Because I have lots of interests in coding style since before.
> 
> I am all for consistency too. My main concern with committing lots of
> coding style patches is that it makes history tracking (svn blame and
> friends) difficult.
> 
> This does not mean that the benefits might not outweight the costs, but
> before sending any patch to Bugzilla it would be good if you came with a
> more detailed proposal of what you want to do and where (and/or a coding
> style proposal for Source/WebKit/efl).
> 
> --
> Raphael Kubo da Costa
> ProFUSION embedded systems
> http://profusion.mobi
> _______________________________________________
> webkit-efl mailing list
> webkit-efl at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-efl