More compact #include statement.

[stayp...@gmail.com]

Hello,

Did little research on this, testing the water with already cold feet.

I find readability and editor estate could be improve if the #include statement would support multiple header files.

 

#include <array> <cstdint> <functional> <iostream> <limits> <memory> <random> <string> <vector>

instead of 

#include <algorithm>
#include <array>
#include <cstdint>
#include <functional>
#include <iostream>
#include <limits>
#include <memory>
#include <random>
#include <string>
#include <vector>

I though about this when opening a file with around 30 #include statement.   With the file header, empty line, the editor with it's 55 viable line showed me nothing of substance.  Maybe a simpler solution would be the editor to support folding of that piece of code. Unfortunately the one I used does not.

For fun I tried the following code, but readability went down the drain. The 2 code formater I use did not expected that usage though ;-)  

#include <algorithm> #include <array> #include <cstdint> #include <functional> #include <iostream> #include <limits>
#include <memory> #include <random> #include <string> #include <vector>

Does that make any sense ?

Regards,

- Mario

[Jake Arkinstall]

Makes sense to me.

I think this exact issue should be made redundant with modules, but I am not aware of module imports currently allowing more than one import per statement. In fact, a "from std import io, math, complex" type of statement (borrowed from python syntax but with C++ naming) in modules would actually be pretty nice. I'm not entirely sure on the status of modules, but someone else here will be able to have more input about this.

[Nicol Bolas]

On Wednesday, March 7, 2018 at 6:57:40 PM UTC-5, stayp...@gmail.com wrote:

Hello,

Did little research on this, testing the water with already cold feet.

I find readability and editor estate could be improve if the #include statement would support multiple header files.

"Readability" in what sense? It may give the file fewer lines, but it's a lot easier to find things and scan items in a vertical list than a horizontal one.

[Marius Bancila]

I have doubts that multiple filenames on the same line would increase readability. Finding a header file by scanning the includes vertically is much easier than doing that horizontally. Here is an example:

#include <ios> <iostream> <istream> <fstream> <ostream> <streambuf> <iomanip>

#include <locale> 

#include <string> <string_view>

#include <map> <vector> <list> <queue> <set> <array>

#include <utility> <algorithm> <functional> <limits>

#include <mutex> <condition_variable> <atomic>

#include <memory>

I don't find it easier to find headers here, and this is a simple example without app or system specific headers. In real life you can get into much more complicated cases, as you mentioned yourself.

IMO this is something editors should be able to do. The IDE I use, Visual Studio, does that pretty well.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7e2d9e7c-fc9b-4913-98bb-007ba5ae8806%40isocpp.org.

[Jonathan Coe]

I would be interested to know what the readability research you did consists of. I’m not sure I agree with the conclusion in this case but it could be useful to assess readability with some clearly defined criteria.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxnYc3T-LjLXvuJ361OmstDo2Wn%2B0hB3-_8rJNRuomyjw%40mail.gmail.com.

[Andrey Semashev]

On 03/08/18 09:44, Marius Bancila wrote:
> I have doubts that multiple filenames on the same line would increase
> readability. Finding a header file by scanning the includes vertically
> is much easier than doing that horizontally. Here is an example:
>
> #include <ios> <iostream> <istream> <fstream> <ostream> <streambuf>
> <iomanip>
> #include <locale>
> #include <string> <string_view>
> #include <map> <vector> <list> <queue> <set> <array>
> #include <utility> <algorithm> <functional> <limits>
> #include <mutex> <condition_variable> <atomic>
> #include <memory>
>
> I don't find it easier to find headers here, and this is a simple
> example without app or system specific headers. In real life you can get
> into much more complicated cases, as you mentioned yourself.

+1, looking through the list of headers vertically is much easier (at
least for me).

> IMO this is something editors should be able to do. The IDE I use,
> Visual Studio, does that pretty well.

I'm not sure what "this" you mean here. IMO, there's nothing to do, all
headers should stay one per line.

[gmis...@gmail.com]

Maybe some simple rules could reduce the typical include list to this:

#include

    ios, iostream, istream, fstream, ostream, streambuf, iomanip,
    locale,
    string, string_view
    map, vector, list, queue, set, array,
    utility, algorithm, functional, limits,
    mutex condition_variable atomic,
    memory;

[Marius Bancila]

I'm not sure what "this" you mean here. IMO, there's nothing to do, all headers should stay one per line.

Sorry about the confusion. I meant that editors should be able to collapse/fold regions of #include directives in order to keep them out of sight so you can focus on the code. Yes, I agree, headers should stay one per line. :)

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/41771dd6-2803-b561-4349-f71f75127415%40gmail.com.

[Richard Hodges]

On 8 March 2018 at 09:57, <gmis...@gmail.com> wrote:

Maybe some simple rules could reduce the typical include list to this:

#include

    ios, iostream, istream, fstream, ostream, streambuf, iomanip,
    locale,
    string, string_view
    map, vector, list, queue, set, array,
    utility, algorithm, functional, limits,
    mutex condition_variable atomic,
    memory;

Shouldn't we just wait for:

from std import cin, cout, vector;

Or whatever syntax is proposed for modules in c++20?  

 

On Thursday, March 8, 2018 at 12:57:40 PM UTC+13, stayp...@gmail.com wrote:

Hello,

Did little research on this, testing the water with already cold feet.

I find readability and editor estate could be improve if the #include statement would support multiple header files.

 

#include <array> <cstdint> <functional> <iostream> <limits> <memory> <random> <string> <vector>

instead of 

#include <algorithm>
#include <array>
#include <cstdint>
#include <functional>
#include <iostream>
#include <limits>
#include <memory>
#include <random>
#include <string>
#include <vector>

I though about this when opening a file with around 30 #include statement.   With the file header, empty line, the editor with it's 55 viable line showed me nothing of substance.  Maybe a simpler solution would be the editor to support folding of that piece of code. Unfortunately the one I used does not.

For fun I tried the following code, but readability went down the drain. The 2 code formater I use did not expected that usage though ;-)  

#include <algorithm> #include <array> #include <cstdint> #include <functional> #include <iostream> #include <limits>
#include <memory> #include <random> #include <string> #include <vector>

Does that make any sense ?

Regards,

- Mario

--

You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/56477ac8-020a-4c21-9d6e-a9cb4f70cdd3%40isocpp.org.

[Barry Revzin]

Python allows you to have multiple imports on a single line, as you're proposing here.

Python's style guide, PEP-8, says not to do it and to use one import per line: https://www.python.org/dev/peps/pep-0008/#imports

[Larry Evans]

On 03/11/2018 06:24 AM, Barry Revzin wrote:
> Python allows you to have multiple imports on a single line, as you're proposing here.
>
> Python's style guide, PEP-8, says not to do it and to use one import per line: https://www.python.org/dev/peps/pep-0008/#imports
>

Doesn't this style of using one import per line violate the DRY principle:

https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

For example:

import os
import sys

although following the PEP-8 guide, violates DRY because 'import' is
repeated.

The same PEP-8 guide, when applied to declarations would say:

int a_scalar, *a_ptr, a_vec[5];

should be:

int a_scalar;
int *a_ptr;
int a_vec[5];

which, again, violates DRY.

So, whichever way is decided, there should be uniform guides:

Either:
one XXX per line;
//violates DRY, but satisfies something like PEP-8.
Or:
multiple XXX's per line;
//to satisfy DRY, but violates PEP-8.
Where:
XXX can be any of:
* c++ #include's
* c++ Declarations
* python imports.

To me, although it violates DRY, the `one XXX per line` guide
clarifies code.

[Todd Fleming]

On Sunday, March 11, 2018 at 8:52:34 AM UTC-4, Larry Evans wrote:

On 03/11/2018 06:24 AM, Barry Revzin wrote:
> Python allows you to have multiple imports on a single line, as you're proposing here.
>
> Python's style guide, PEP-8, says not to do it and to use one import per line: https://www.python.org/dev/peps/pep-0008/#imports
>
Doesn't this style of using one import per line violate the DRY principle:

https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

For example:

   import os
   import sys

If that's DRY, then DRY is unusable:

f(a,b);
...
f(c,d); // oops.We should never call f() anywhere else because DRY.

[j c]

Hear hear 

[Larry Evans]

OK, to be more explicit:

There's no *semantic* difference between:

import os
import sys

and:

import os,sys

but there *is* a semantic difference between:

f(a);
...
f(b);

and:

f(a),(b);
...

which isn't even legal.

Thus:

f(a);
...
f(b);

is *not* violating DRY.

[Todd Fleming]

On Sunday, March 11, 2018 at 1:12:48 PM UTC-4, Larry Evans wrote:

OK, to be more explicit:

There's no *semantic* difference between:

   import os
   import sys

and:

   import os,sys

Python has a very unique culture, one that values DRY more than any community I'm aware of. Yet the Python community, the high priests of DRY, don't buy your argument.

 

[Larry Evans]

You're misunderstanding my viewpoint. My OP said:

To me, although it violates DRY, the `one XXX per line` guide
clarifies code.

Thus I was *advocating* the "one XXX per line":

import os
import sys

I mentioned the DRY principle *solely* to provide a possible
justification for the "multiple XXX per line":

import os,sys

method. Personally, I find the "multiple XXX per line":

SomeType a_scalar, *a_ptr, a_vec[5];

more obscure, but that's what's allowed by current c and c++.
I assume the K&R allowed that to save typing and *some* people
*would* use the DRY argument in favor of "multiple XXX per line"
versus the "one XXX per line":

SomeType a_scalar;
SomeType *a_ptr;
SomeType a_vec[5];

Again, I'm not advocating "multiple XXX per line", I'm just
saying it could be used by *some* (not me) people.

Hope that clarifies my position.

-regards,
Larry

[Todd Fleming]

It does clarify.

Yes, the SomeType example is more obscure; a lot of coding standards documents rightly ban it. Now if I could just force myself to stop doing that on occasion out of laziness...

Todd

[inkwizyt...@gmail.com]

but `import` is keyword, if we replace it by `!` then:

!sys
!os

Do repeating anything? No.

Volition of DRY would be when you write:

!sys
!sys

BTW How do you want write any thing using C++ templates? You need repeat multiple times `typename` and `template`.

In reality only true place where include/import have truly violate DRY principle is when you write:

include sys
include os
include foo
include bar

in multiple DIFFERENT files. If it only exists in one file this is fully conforming, at least for me.
Each line do one independent thing from rest of lines.

Another similar thing:

call sys;
call os;
call foo;
call bar;

Is this violate DRY? different meaning and keyword but same structure.

I understand DRY as: "do not repeat things that can change", therefore `include` or `call` do not fall under it because they do not change at all, they part of syntax.

[Miguel Ojeda]

On Sun, Mar 11, 2018 at 7:47 PM, Larry Evans <cpplj...@suddenlink.net> wrote:
> On 03/11/2018 12:20 PM, Todd Fleming wrote:
>>
>> On Sunday, March 11, 2018 at 1:12:48 PM UTC-4, Larry Evans wrote:
>>>
>>>
>>> OK, to be more explicit:
>>>
>>> There's no *semantic* difference between:
>>>
>>> import os
>>> import sys
>>>
>>> and:
>>>
>>> import os,sys
>>>
>>>
>> Python has a very unique culture, one that values DRY more than any
>> community I'm aware of. Yet the Python community, the high priests of DRY,
>> don't buy your argument.
>>
>
> You're misunderstanding my viewpoint. My OP said:
>
> To me, although it violates DRY, the `one XXX per line` guide
> clarifies code.
>
> Thus I was *advocating* the "one XXX per line":
>
> import os
> import sys
>
> I mentioned the DRY principle *solely* to provide a possible
> justification for the "multiple XXX per line":
>
> import os,sys
>
> method. Personally, I find the "multiple XXX per line":
>
> SomeType a_scalar, *a_ptr, a_vec[5];

I typically only find that style useful in the init statement of for
loops to declare a logically constant end variable in a for loop,
whenever one has to be sure it is not re-evaluated every iteration,
i.e:

for (int i = 0, iEnd = get_size(); i < iEnd; ++i) { ... }

And even in that case, if it is anything non-trivial, I usually prefer
to just keep it in the previous line as a proper const variable. So
the only real benefit of the style is the lifetime reduction/scope
pollution for trivial cases.

For normal variable declarations, having only per line not only
improves readability (specially for complex types, i.e. C++), but also
allows you to have straightforward patches/diffs, i.e.:

@@ -1,5 +1,6 @@
#include <iostream>
#include <map>
+#include <sstream>
#include <string>
#include <vector>

vs.

@@ -1,2 +1,2 @@
-#include <iostream> <map> <string> <vector>
+#include <iostream> <map> <sstream> <string> <vector>

Same applies for C/C++ #includes and Python imports.

Cheers,
Miguel