RESOLVED DUPLICATE of bug 69481 Bug 65179
WebKit2 GTK public headers should have the same style rules rules than WebKit1
https://bugs.webkit.org/show_bug.cgi?id=65179
Summary WebKit2 GTK public headers should have the same style rules rules than WebKit1
Carlos Garcia Campos
Reported 2011-07-26 06:30:36 PDT
Source/WebKit2/UIProcess/API/gtk/WebKitWebView.h:63: Extra space before ( in function call [whitespace/parens] [4] Source/WebKit2/UIProcess/API/gtk/WebKitWebView.h:66: Extra space before ( in function call [whitespace/parens] [4] Source/WebKit2/UIProcess/API/gtk/WebKitWebView.h:69: Extra space before ( in function call [whitespace/parens] [4] Source/WebKit2/UIProcess/API/gtk/WebKitWebView.h:69: The parameter name "webView" adds no information, so it should be removed. [readability/parameter_name] [5] Source/WebKit2/UIProcess/API/gtk/WebKitWebView.h:73: The parameter name "webView" adds no information, so it should be removed. [readability/parameter_name] [5] Source/WebKit2/UIProcess/API/gtk/WebKitWebView.h:73: Extra space before ( in function call [whitespace/parens] [4] Source/WebKit2/UIProcess/API/gtk/WebKitWebView.h:76: The parameter name "webView" adds no information, so it should be removed. [readability/parameter_name] [5] Source/WebKit2/UIProcess/API/gtk/WebKitWebView.h:76: Extra space before ( in function call [whitespace/parens] [4] These are all false positives.
Attachments
Patch (1.14 KB, patch)
2011-07-26 06:32 PDT, Carlos Garcia Campos
mrobinson: review-
Carlos Garcia Campos
Comment 1 2011-07-26 06:32:34 PDT
Martin Robinson
Comment 2 2011-07-26 07:02:06 PDT
Comment on attachment 101994 [details] Patch If possible it would be better to ignore only the headers. This change ignores headers and source files.
Carlos Garcia Campos
Comment 3 2011-07-26 08:03:31 PDT
(In reply to comment #2) > (From update of attachment 101994 [details]) > If possible it would be better to ignore only the headers. This change ignores headers and source files. There will be false positives in the files too, like code generated from macros like G_DEFINE_TYPE.
Martin Robinson
Comment 4 2011-07-26 08:07:17 PDT
(In reply to comment #3) > There will be false positives in the files too, like code generated from macros like G_DEFINE_TYPE. It makes sense to fix those as wel find them as well. I can help out with that.
Carlos Garcia Campos
Comment 5 2011-07-26 08:16:37 PDT
(In reply to comment #4) > (In reply to comment #3) > > > There will be false positives in the files too, like code generated from macros like G_DEFINE_TYPE. > > It makes sense to fix those as wel find them as well. I can help out with that. what do you mean by fix them? I think we should use gobject macros for maintainability reasons.
Martin Robinson
Comment 6 2011-07-26 08:38:11 PDT
(In reply to comment #5) > what do you mean by fix them? I think we should use gobject macros for maintainability reasons. Oh, I mean we can fix the style checker to not complain about G_DEFINE_TYPE lines as well as GObject method names.
Carlos Garcia Campos
Comment 7 2011-07-26 08:41:00 PDT
(In reply to comment #6) > (In reply to comment #5) > > > what do you mean by fix them? I think we should use gobject macros for maintainability reasons. > > Oh, I mean we can fix the style checker to not complain about G_DEFINE_TYPE lines as well as GObject method names. Ah! that would be awesome :-)
Carlos Garcia Campos
Comment 8 2011-10-06 00:00:12 PDT
*** This bug has been marked as a duplicate of bug 69481 ***
Note You need to log in before you can comment on or make changes to this bug.