On Sat, Oct 31, 2009 at 7:21 PM, Wolodja Wentland
<wentl...@cl.uni-heidelberg.de> wrote:
> On Sat, Oct 31, 2009 at 18:29 -0500, Peng Yu wrote:
>> On Sat, Oct 31, 2009 at 5:45 PM, Wolodja Wentland
>> <wentl...@cl.uni-heidelberg.de> wrote:
>> > On Sat, Oct 31, 2009 at 16:53 -0500, Peng Yu wrote:
>
>> > Are you serious? Do you *really* put each function in its own file? How
>> > exactly does this enhance the readability of the source code? Especially
>> > if you compare that to a (sic!) modularisation scheme that groups
>> > classes and functions together by task or semantic relatedness.
>
>> If two functions are too long to put in file, I generally put them in
>> two different files.
>
> If it should ever happen that two functions are too long to put in a
> single file you should refactor your code. It is usually a good idea of
> breaking problems down into single steps (ie functions) so you never end
> up with a 5000 SLOC *function*.
My definition of long is more than one screen.
> How do functions of this length enhance the readability of your source
> code?
If the code is of one screen, you can easily see what it does without
having to scroll back and forth.
>> And I always put a single class in a file.
>
> Why? What do you gain by that?
It makes me easier to look for an class. I can just search the
filename to get a class. By looking at the packages imported in the
file, I can easily see what packages a class depends. If there are
multiple classes in a file, I will not know which packages a class
actually depends on.
>> Suppose that I have many functions in one file, it is not clear to see
>> how many functions are in the file at first glance.
>
> Use a better editor/IDE for that.
What editor you use? I use vim. I'm sure there is a way to configure
vim to fold the definition of a class. But I don't use it because I
feel folding and unfolding code is not convenient.
> [snip]
>
> I thought about answering your post in greater detail, but i would like
> to evaluate your style of work first. Is there any place where I can
> have a look at some of your source code? It would be perfect if it is a
> medium sized project with said unit tests, packages and
> function-modules and the rest you described.
I just started writing python code. So I don't have much code to show
you now. But I have written a project of 25,000 lines of code in C++.
In this project, I always have a file for a class. My directory
structure looks like the following (toward the end). But having this
structure it is every easy to navigate to any class or function.
Please let me know if you need any more information.
src/ has all the source code and testing code. Because I usually need
to change source code and the corresponding test code at the same
time, I put them close to each other.
include/ has links to all the header files and maintains the directory
structure (include/ is generated automatically based on the content of
src/). All .cpp files are linked to lib/, where the library file is
made.
The unit test for divide is in main.cpp.
| |-- divide.cpp
| |-- divide.hpp
| `-- main.cpp
When test cases become big, I separate them into multiple main.cpp
files like below.
| |-- half
| | |-- Makefile
| | |-- cap
| | | |-- Makefile
| | | `-- main.cpp
| | |-- half.hpp
| | |-- is_interleaved
| | | |-- Makefile
| | | `-- main.cpp
| | |-- less_than
| | | |-- Makefile
| | | `-- main.cpp
| | `-- main
| | |-- Makefile
| | `-- main.cpp
The namespace is defined accordingly. For example, class divide.hpp is
in numerical/divide.hpp, therefore, I use numerical::divide to refer
it.
### example directory structure
.
|-- include
| `-- numerical
| |-- divide.hpp -> ../../src/divide/divide.hpp
| |-- interval
| | |-- combine_half.hpp ->
../../../src/interval/combine_half/combine_half.hpp
| | |-- half.hpp -> ../../../src/interval/half/half.hpp
| | |-- linear.hpp -> ../../../src/interval/linear/linear.hpp
| | `-- rotated.hpp -> ../../../src/interval/rotated/rotated.hpp
| `-- smart_increment.hpp -> ../../src/smart_increment/smart_increment.hpp
|-- lib
| |-- Makefile
| |-- libnumerical.so -> libnumerical.so.1
| |-- libnumerical.so.1 -> libnumerical.so.1.0.0
| `-- numerical
| `-- divide.cpp -> ../../src/divide/divide.cpp
`-- src
|-- Makefile
|-- divide
| |-- Makefile
| |-- divide.cpp
| |-- divide.hpp
| `-- main.cpp
|-- interval
| |-- Makefile
| |-- combine_half
| | |-- Makefile
| | |-- combine_half.hpp
| | `-- main.cpp
| |-- half
| | |-- Makefile
| | |-- cap
| | | |-- Makefile
| | | `-- main.cpp
| | |-- half.hpp
| | |-- is_interleaved
| | | |-- Makefile
| | | `-- main.cpp
| | |-- less_than
| | | |-- Makefile
| | | `-- main.cpp
| | `-- main
| | |-- Makefile
| | `-- main.cpp
`-- smart_increment
|-- Makefile
|-- main.cpp
`-- smart_increment.hpp
> Why does not a single module in in the stdlib follow your code layout
> scheme?
>
> regards
>
> Wolodja
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCAAGBQJK7NSXAAoJEIt/fTDK8U78EvAP/2SGRm/FxnoSw1jr3MDxc4Gp
> Y8RichWXliSjGcRXKw5R3pk2SkAkmmCW0TgR2Pxn75hTi9XQ5KOTXgGNKMQVeYox
> QtejLw2e1ITPwd1dT/dkZQdfzL7jpdtvsod+uv0gPTcbTlwmyRnveneA1v0gBw2U
> tlHz5VeCaK3cakvQBunESnz3lcnpt1uMMrG7ZRhweAsV2mB2quEZGmDt+6FfcL7g
> M7wavW7EfNbdCa882oGzqgbZtY526tDkm+u478eObTx4MkFDo5ERkVBAU0KpoPwR
> mU7/FYnvv+ergy7U9HVAtQy2uQNABVaN6qDl025YqsCXmcJCf+JiunE+HhOR96LZ
> fr08p8MjP3n/enhKXizRuc904xljSh2D7eWo/SWy0mkP87BRw657bIJl1S6vG28Q
> qvTc/ke6lxvRRtSMjeRDLCQJuco6DpN6chD88ZA0L8sJwBaUsQeUBBXF8j2yfza/
> pn2AZ5H+CZVeX59md35U9yyZnrkASoMP6bYbEUROAWZDQV+Nvb00itAwhagPGHwC
> pnMk+ALjWpMa8ltwGFt9jGFDfmNNhiL69i/vhVV4d8oGqv4k3YjxqCzMAGYGGluR
> cMN/HowHPhCY+ZbCiDwbY1wsnfGlnPXZqtnC92evmGQBXJtcwdRtMLM+wMvDKgeW
> L4mk6Iu8vhAaS9KEu2C4
> =8V6q
> -----END PGP SIGNATURE-----
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>
--
http://mail.python.org/mailman/listinfo/python-list
