Hello,
Was reading the coding-style documentation. Have just one question concerning
C++ null pointer value. Quoting the coding-style docs, In C++, the null pointer
value should be written as 0.
My question is: Doesn't xcode clang now support features like nullptr? Shouldn't
the coding-style
On Fri, Apr 12, 2013 at 3:33 PM, Karen Shaeffer shaef...@neuralscape.comwrote:
Was reading the coding-style documentation. Have just one question
concerning
C++ null pointer value. Quoting the coding-style docs, In C++, the null
pointer
value should be written as 0.
My question is: Doesn't
On Saturday 13 April 2013, Karen Shaeffer wrote:
Hello,
Was reading the coding-style documentation. Have just one question
concerning C++ null pointer value. Quoting the coding-style docs, In C++,
the null pointer value should be written as 0.
My question is: Doesn't xcode clang now support
On Fri, Apr 12, 2013 at 03:41:17PM -0700, Benjamin Poulain wrote:
On Fri, Apr 12, 2013 at 3:33 PM, Karen Shaeffer
shaef...@neuralscape.comwrote:
Was reading the coding-style documentation. Have just one question
concerning
C++ null pointer value. Quoting the coding-style docs, In C++,
On Fri, Apr 12, 2013 at 4:09 PM, Karen Shaeffer shaef...@neuralscape.comwrote:
Of course, I understand that. But there is a huge opportunity cost to
webkit.
The c++11 standard also rewrites the entire standard library. I have been
using
g++ 4.7.2 using -stdc++11 in my work with linux. And
On Fri, Apr 12, 2013 at 4:09 PM, Karen Shaeffer shaef...@neuralscape.comwrote:
On Fri, Apr 12, 2013 at 03:41:17PM -0700, Benjamin Poulain wrote:
On Fri, Apr 12, 2013 at 3:33 PM, Karen Shaeffer
shaef...@neuralscape.comwrote:
Was reading the coding-style documentation. Have just one
, we would run into compiler
portability problems.
If someone figures out how to be clear on that point, where it should and
should not be used, we should indeed update the coding style and the coding
style document.
-- Darin___
webkit-dev mailing list
On Fri, Jan 28, 2011 at 10:21 AM, Peter Kasting pkast...@google.com wrote:
On Fri, Jan 28, 2011 at 10:14 AM, Alexey Proskuryakov a...@webkit.orgwrote:
Do you have any specific mechanism in mind for keeping global comments
accurate?
No more than I have for keeping API usage or function
31.01.2011, 11:47, Ryosuke Niwa rn...@webkit.org:
How can we ensure that all comments are up to do date? For example, suppose
function A calls B, and B calls C. Then in the call site of A, I comment
Because A does X, we do Y. Now suppose for the moment that the behavior X
of A is
2011/1/31 Konstantin Tokarev annu...@yandex.ru
You can document A as function calling B, B as function calling C, and keep
documentation of C up to date when it's behavior changes
I don't see how that can substitute my comment that Because A does X, do
Y. Saying do Y because we call A isn't
On Mon, Jan 31, 2011 at 12:47 AM, Ryosuke Niwa rn...@webkit.org wrote:
How can we ensure that all comments are up to do date? For example, suppose
function A calls B, and B calls C. Then in the call site of A, I comment
Because A does X, we do Y. Now suppose for the moment that the behavior
On Mon, Jan 31, 2011 at 4:54 PM, Aaron Boodman a...@chromium.org wrote:
It seems like the one line patch to C just broke A. It had a
dependency on the behavior of C that was worth documenting. Now you
have changed C and the behavior of A is probably wrong (or at least
wasteful).
Not
On Mon, Jan 31, 2011 at 5:23 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Jan 31, 2011 at 4:54 PM, Aaron Boodman a...@chromium.org wrote:
It seems like the one line patch to C just broke A. It had a
dependency on the behavior of C that was worth documenting. Now you
have changed C and the
On Jan 31, 2011, at 5:48 PM, Aaron Boodman wrote:
On Mon, Jan 31, 2011 at 5:23 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Jan 31, 2011 at 4:54 PM, Aaron Boodman a...@chromium.org wrote:
It seems like the one line patch to C just broke A. It had a
dependency on the behavior of C that
On Sun, Apr 18, 2010 at 4:11 PM, Maciej Stachowiak m...@apple.com wrote:
That reminds me, we should turn off the 80-column limit on bugs.webkit.org -
there's no need for it to hard-wrap your text.
Great, I was wondering about that. I filed a report for that here:
I wanted to add a couple comments and a question to this discussion.
On Fri, Apr 16, 2010 at 2:54 PM, Maciej Stachowiak m...@apple.com wrote:
I haven't contributed to WebKit's Python code yet, but I will say that I
agree with Eric's sentiments here. 80-column limit is archaic and pointless.
On Apr 18, 2010, at 12:33 PM, Chris Jerdonek wrote:
I wanted to add a couple comments and a question to this discussion.
On Fri, Apr 16, 2010 at 2:54 PM, Maciej Stachowiak m...@apple.com
wrote:
I haven't contributed to WebKit's Python code yet, but I will say
that I
agree with Eric's
bike-shedding
I think 80 columns is a waste of time and hurts readability.
Instead of being smart about when we wrap code, 80 adheres to a
blanket rule, discourages long variable/function names, and needlessly
expands code vertically ignoring modern wider-than-long monitors.
The optparse code
On Apr 16, 2010, at 1:48 PM, Eric Seidel wrote:
bike-shedding
I think 80 columns is a waste of time and hurts readability.
Instead of being smart about when we wrap code, 80 adheres to a
blanket rule, discourages long variable/function names, and needlessly
expands code vertically ignoring
(I have contributed but not often.) I also agree with 80 columns hurts
readability.
It doesn't take much looking to show a
lothttp://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/layout_tests/run_webkit_tests.py#L135of
I think having longer lines of code hurts readability. There is lots
of typographic evidence
to back this up ( e.g.
http://webtypography.net/Rhythm_and_Proportion/Horizontal_Motion/2.1.2/.
Of
course, the typographic commentary applies to text rather than code,
and most text isn't indented,
but I
Hi all,
As I'm sure the discussions in the webkit meeting over the past two
days made clear, it looks like most of our non-C++ code is getting
written in Python. Back in January, Adam Barth posted this thread [1]
where I thought it was agreed we would attempt to follow PEP 8 ([2] -
the standard
22 matches
Mail list logo
