You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2012/01/05 22:56:16 UTC
Style violations
modules\proxy\mod_proxy.h entirely violates our 80 column rule,
which is particularly offensive owing to the fact that the .h
files are the easiest reference outside of doxygen for developers
to become familiar with httpd entry points, and aught to be not
only editable, but also printable.
Would the culprits please clean up before the next 2.4 tag?
Re: Style rule change?
Posted by HyperHacker <hy...@gmail.com>.
On Sun, Jan 8, 2012 at 23:29, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> On 1/8/2012 12:04 PM, Guenter Knauf wrote:
>> on the other side: I've asked me already often if we shouldnt increase the maxchar/line; I
>> believe that would in many cases greatly increase readability ...
>> and honestly: who the heck does nowadays work on a 80-line terminal??
>
> Frequently on unix and windows. I haven't yet committed the time to
> try working on a headless windows server 2008, however :) My text
> editor windows all default to 81 cols to avoid just this issue.
>
>> isn't that a relic inherited from stone-time? I would be fine with f.e. 110 or 120 chars/line.
>
> Is a limit even appropriate anymore? On what basis? 132 chars is one
> standard that could be applied. Perhaps a precommit filter to avoid
> issues in the future?
I can nicely fit 3 editor windows at 80 columns on my screen. It's very handy.
--
Sent from my toaster.
Re: Style rule change?
Posted by Ruediger Pluem <rp...@apache.org>.
William A. Rowe Jr. wrote:
> On 1/8/2012 12:04 PM, Guenter Knauf wrote:
>> on the other side: I've asked me already often if we shouldnt increase the maxchar/line; I
>> believe that would in many cases greatly increase readability ...
>> and honestly: who the heck does nowadays work on a 80-line terminal??
>
> Frequently on unix and windows. I haven't yet committed the time to
> try working on a headless windows server 2008, however :) My text
> editor windows all default to 81 cols to avoid just this issue.
>
>> isn't that a relic inherited from stone-time? I would be fine with f.e. 110 or 120 chars/line.
>
> Is a limit even appropriate anymore? On what basis? 132 chars is one
> standard that could be applied. Perhaps a precommit filter to avoid
> issues in the future?
>
I think we should stick with the 80 chars/line for email and multiple terminals in parallel.
Regards
Rüdiger
Style rule change?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/8/2012 12:04 PM, Guenter Knauf wrote:
> on the other side: I've asked me already often if we shouldnt increase the maxchar/line; I
> believe that would in many cases greatly increase readability ...
> and honestly: who the heck does nowadays work on a 80-line terminal??
Frequently on unix and windows. I haven't yet committed the time to
try working on a headless windows server 2008, however :) My text
editor windows all default to 81 cols to avoid just this issue.
> isn't that a relic inherited from stone-time? I would be fine with f.e. 110 or 120 chars/line.
Is a limit even appropriate anymore? On what basis? 132 chars is one
standard that could be applied. Perhaps a precommit filter to avoid
issues in the future?
Re: Style violations
Posted by Niklas Edmundsson <ni...@acc.umu.se>.
On Mon, 9 Jan 2012, Sander Temme wrote:
>
> On Jan 9, 2012, at 11:35 AM, André Malo wrote:
>
>> Here it's 80 chars (actually I'm use 78 personally) both about putting
>> multiple editors side by side and keeping diffs readable by email clients.
>
>
> I'm in much the same mode: multiple 80 char wide windows
> side-by-side. I would favor keeping the 80 char limit unless the
> message (code or otherwise) benefits from expression in a wider
> format. For that reason, not elated about automated post-commit
> enforcement.
+1
Fitting six 80x40 terminals on a single screen is quite handy when
working at multiple files at the same time, that gets cumbersome if
each file gets ad hoc widths especially when you mix headers/files of
different origins (say libs used by $project). Sure, the
terminal/viewer/editor wraps but the readability is crap.
I've seen code written by people with random-sized terminals (usually
the size they could comfortably use on their laptop of the time), and
even themselves tend to resort to running indent over the lot a few
years later when they need to print/overview/whatever...
So, 80 cols but with the exception mentioned by Sander above has my
vote.
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | nikke@acc.umu.se
---------------------------------------------------------------------------
You made a living doing this? - Guinan
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: Style violations
Posted by Sander Temme <sc...@apache.org>.
On Jan 9, 2012, at 11:35 AM, André Malo wrote:
> Here it's 80 chars (actually I'm use 78 personally) both about putting
> multiple editors side by side and keeping diffs readable by email clients.
I'm in much the same mode: multiple 80 char wide windows side-by-side. I would favor keeping the 80 char limit unless the message (code or otherwise) benefits from expression in a wider format. For that reason, not elated about automated post-commit enforcement.
S.
--
sctemme@apache.org http://www.temme.net/sander/
PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A
View my availability: http://tungle.me/sctemme
Re: Style violations
Posted by André Malo <nd...@perlig.de>.
* Guenter Knauf wrote:
> Am 08.01.2012 17:20, schrieb Jim Jagielski:
> > How much is "entirely"?
> >
> > Do the>80char lines in ap_listen.h, ap_mmn.h, ap_mpm.h, ap_provider.h,
> > ap_regex.h, ap_regkey.h, ap_slotmem.h, http_core.h, http_protocol,h,
> > etc etc etc etc also constitute a rating of "entirely"?
> >
> > I'd look for more, but my time is better spent fixing things that
> > I find need-to-be-fixed rather than just pointing them out...
> >
> :-)
>
> on the other side: I've asked me already often if we shouldnt increase
> the maxchar/line; I believe that would in many cases greatly increase
> readability ...
> and honestly: who the heck does nowadays work on a 80-line terminal??
> isnt that a relic inherited from stone-time? I would be fine with f.e.
> 110 or 120 chars/line.
Here it's 80 chars (actually I'm use 78 personally) both about putting
multiple editors side by side and keeping diffs readable by email clients.
Also, but that's for me, it's way more readable if it's not that wide.
nd
--
Gib' mal folgendes in die Kommandozeile ein (und einen Moment warten):
net send localhost "Buuuh!"
Na, erschreckt? -- Markus Becker in mpdsh
Re: Style violations
Posted by Guenter Knauf <fu...@apache.org>.
Am 08.01.2012 17:20, schrieb Jim Jagielski:
> How much is "entirely"?
>
> Do the>80char lines in ap_listen.h, ap_mmn.h, ap_mpm.h, ap_provider.h,
> ap_regex.h, ap_regkey.h, ap_slotmem.h, http_core.h, http_protocol,h,
> etc etc etc etc also constitute a rating of "entirely"?
>
> I'd look for more, but my time is better spent fixing things that
> I find need-to-be-fixed rather than just pointing them out...
:-)
on the other side: I've asked me already often if we shouldnt increase
the maxchar/line; I believe that would in many cases greatly increase
readability ...
and honestly: who the heck does nowadays work on a 80-line terminal??
isnt that a relic inherited from stone-time? I would be fine with f.e.
110 or 120 chars/line.
Gün.
Re: Style violations
Posted by Ben Laurie <be...@links.org>.
On Sun, Jan 8, 2012 at 4:20 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> How much is "entirely"?
>
> Do the >80char lines in ap_listen.h, ap_mmn.h, ap_mpm.h, ap_provider.h,
> ap_regex.h, ap_regkey.h, ap_slotmem.h, http_core.h, http_protocol,h,
> etc etc etc etc also constitute a rating of "entirely"?
>
> I'd look for more, but my time is better spent fixing things that
> I find need-to-be-fixed rather than just pointing them out...
Was tempted to comment first time round - if Bill objects, why does he
not just commit a fix?
Not _quite_ as irritating as the demands I used to resist on a regular
basis to fix bugs in my commits on platforms I did not have access to,
but getting up there.
>
> On Jan 5, 2012, at 4:56 PM, William A. Rowe Jr. wrote:
>
>> modules\proxy\mod_proxy.h entirely violates our 80 column rule,
>> which is particularly offensive owing to the fact that the .h
>> files are the easiest reference outside of doxygen for developers
>> to become familiar with httpd entry points, and aught to be not
>> only editable, but also printable.
>>
>> Would the culprits please clean up before the next 2.4 tag?
>>
>
Re: Style violations
Posted by Jim Jagielski <ji...@jaguNET.com>.
How much is "entirely"?
Do the >80char lines in ap_listen.h, ap_mmn.h, ap_mpm.h, ap_provider.h,
ap_regex.h, ap_regkey.h, ap_slotmem.h, http_core.h, http_protocol,h,
etc etc etc etc also constitute a rating of "entirely"?
I'd look for more, but my time is better spent fixing things that
I find need-to-be-fixed rather than just pointing them out...
On Jan 5, 2012, at 4:56 PM, William A. Rowe Jr. wrote:
> modules\proxy\mod_proxy.h entirely violates our 80 column rule,
> which is particularly offensive owing to the fact that the .h
> files are the easiest reference outside of doxygen for developers
> to become familiar with httpd entry points, and aught to be not
> only editable, but also printable.
>
> Would the culprits please clean up before the next 2.4 tag?
>