I don't see the point to link the logical structure of the code with the IDE or editor you use. There is no link between them, or it is a good practice NOT to do any assumption. If one want to code with vi/emacs/sublime or eclipse or any other one, the build system and structure of the code should be agnostic. For me the current structure of code of rust is totaly acceptable, even though I would recommend to place unit test in a submodule of the tested one (ie just splitting the code and its unit test in two files), but that is just a policy you can enforce in your project (is there a lint for that?). Same for the "one class per module". Maybe having triggerable linter can help people choosing there convention.
What really annoy me is the fact that public method/class are not easilly described in one place. On one hand, I like the headers in C++ where you have a clear way of seeing which are the class/function your module provides, with private stuff being pushed aside. To be more accurate, I like the declaration/definition splitting of function. However the python or java way is really handful where you just write the code directly. I don't know which is best, I have the feeling rust is in the middle, but I sometime don't see clearly in the rust code the list of public methods of a given class. Maybe there is room for improvement. For the internal visibility, I really enjoy the python's way of life "you can access to anything at your own risk", however I finally don't think it's a good practice. If you end up doing that, your design is wrong... except for unit test where is it really useful to have direct and easy access to private member to mock it... ----- Gaetan 2014/1/24 Patrick Walton <pcwal...@mozilla.com> > On 1/23/14 8:39 PM, Damien Radtke wrote: > >> I will say that I actually really like Go's approach to modules. It uses >> a folder -> module mapping instead, so a module can consist of any >> number of source files provided they all live in the same directory. If >> you prefer your modules to be one big source file each, then that's >> easily done, but those who want to break a module up into several files >> can do so easily. >> > > My issue with Go's approach is that you lose the ability to see where an > identifier came from by simply searching through the buffer you have open; > you have to grep in the current directory. > > Patrick > > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
