Thanks a lot to all of you !
I am really just starting to 'learn becoming an "efficient" programmer' (i have started almost from scratch), and your help is very appreciated.

Your messages made me realize a bit more that each person and project can/should have a workflow that suits it.
It can be the same as other persons/project, for the sake of compatibility or easier communication. Or it can be personal and unique for the sake of efficiency, if there is no need for communication and work protocols.

I work alone on my code (it might change some day - who knows), so i understand BrowserUk's efficiency motivations. And i would like to be able to work with others some day, so i want to try and learn a bit of Revision Control and "Test::* testing" for example.

In your messages i have learned many things :

- That i don't need to create 5 different Module::Starter directories for my 5 modules, and that makes quite a big difference in terms "lib" thingies.

- That i could use

perl -I
[download]

- An alternative idea for having "non-boolean tests" directly in the source. What i don't like about it, is that it makes the source less readable : it becomes harder to search the interesting parts of the code.
But i like that it is run each time i run my code, and that i can be more creative than "ok". But...i like "ok" because it is easy to share : everybody understands what it means, when it appears on the screen.

- A clear tutorial on Revision Control

- Easier ways to manage my tests and run them, and a text about Regression Testing that i will most probably read.

... and a nice story !

Now i know how i want to start developing my own modules. Until now i felt lost in the profusion of tools and techniques, and by tiny details which make big differences (my 5 Module::Starter directories where a real pain).

Thank you, you're all great!

An alternative idea for having "non-boolean tests" directly in the source. What i don't like about it, is that it makes the source less readable : it becomes harder to search the interesting parts of the code.

I think you got the wrong end of the stick about this.

In the normal way of things, a module, Your::Thing.pm, looks like this:

package Your::Thing;

## The subroutines and stuff that implement your module

1; ## finish with a true value to satisfy require/use
[download]

And the tests live in a bunch of .t files.

The "alternative idea" is that Your::Thing.pm looks like this:

package Your::Thing;

## The subroutines and stuff that implement your module

return 1 if caller; ## return a true value and exit when loaded as a m
+odule
package main;

### Write tests that use Your::Thing here.

...
[download]

You use the module in the normal way via use or require, and it works exactly as with the 'usual way' above.

To run the tests, you type:

>perl \Perl\site\lib\Your::Thing.pm
[download]

And the code that comes after the return 1 if caller; statement gets run. It really is as simple as that.

And whilst the tests and code exist in the same file, the module code is above that line, and the tests are below it. There is no interleaving. Nothing is "less readable". Nothing is "harder to search" for.

Indeed, maintenance is greatly simplified by having the code and tests within the same file.

Try it. You'll never go back :)

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Indeed, maintenance is greatly simplified by having the code and tests within the same file.

It can be, depending on the project.

I'm no longer a fan of the "you must have one .t file for each logical module in your program" rule. I prefer my test files to have their own logical relationships, where each file tests one function of the program in a particular way. For example, in the Pod::PseudoPod::DOM test suite, I have separate subdirectories for each type of formatter and separate test files for each category of transformation (escapes, environments, block-level items, tables, and so on).

This does require a little bit of testing infrastructure, but organizing more than a few tests is like organizing more than a few lines of code. You choose the best option based on what you're doing and you change it to work better when it becomes necessary or obvious.

To me, the 3 of them seem to do exactly the same : give the information of "where are these sources that i need". PERL5LIB does it through an environment variable, lib does it in each source file, and -I does it on the command line. Any other difference?

Ultimately there's only one way of telling Perl where to search for modules: the global @INC array - it's a list of directories that Perl uses to search for libraries. PERL5LIB and "-I" are just ways of informing Perl to pre-populate @INC with certain directories.

And use lib just manipulates @INC while your code is being compiled. (You can look at lib.pm and see what's going on - there's nothing especially mysterious.)

They're each useful in different ways.

If you have some paths that you always (or nearly always) want Perl to search in, then use the environment variable. You can set it in your .bashrc/.tcshrc or some other script that is executed as soon as you log in, and forget all about it.

use lib is useful if you want to hard-code library paths that will be searched for specific scripts. It's not especially good for code you hope to publish for other people to install and use though, because they might plan on installing modules somewhere else. Relative paths can also be problematic with use lib because they are treated relative to the directory Perl was executed in, not relative to the file in which the use lib appears. (There are modules like "lib::abs" which improve the situation.)

The -I argument for perl is useful for most other situations. It tends to be what I use when I'm testing Perl modules I've written and intend to publish. I'll use a directory structure like this:

  p5-my-module/
        lib/
              My/
                    Module.pm
        examples/
              demo.pl
        t/
              00basic.t
              01advanced.t
        xt/
              01pod.t
              02pod_coverage.t

Then I'll have my terminal mostly in p5-my-module, and I can run things like:

perl -Ilib t/00basic.t
perl -Ilib examples/demo.pl

I find that use lib can be handy used within test suites to help the test cases find additional testing modules (which might be inside "p5-my-module/t/lib/"). This is because although use lib isn't great for stuff that's getting installed on other people's machines, test suites don't get installed, and they are run in a very predictable way.

Beginner question (i searched vainly for this basic information) :
What happens if i install a module (make install), and then want to use its uninstalled development version?
Is this when i should use perl -I ? Will @INC react as i wish it will?

Thanks for the tips on tests BrowserUk, really good !
I will do it your way for now. And it's always possible to .t files if i ever want to.
Here are a few reasons why i think it could be worth the try: - they are not all in the same file, so i don't risk to have variables 'collision' (same variable in two unrelated tests). - it is easier for someone who installs the module (or even just myself after 6 months) to understand what happens, know in which file to look (and each of them are a lot smaller - no need to search around), and understand what 'ok' means without needing to think about how the testing algorithm works. - it enables to use Coverage tools. If i understood properly what they do, thanks to them you will be less likely to forget to test any part of your code, which will result in easier maintenance.
Especially when you get this nasty bug in a part of your code that you didn't look at for 6 months
=> there will be a test there to clearly indicate what didn't work and where. You might have forgotten to put this test there if you hadn't use test coverage.

Thus, testing with .t files makes things easy for others and for yourself (in the future), and it doesn't seem to be so much work to set them up : just paste a piece of test code into a .t file and add some ok() statements... and you will have to use 'prove' quite often, which you could automate with an alias every time you run your code.
Well, it is quite some work to create these .t files, and the more you will create, the more you will think of adding ("and what if... ok, let's add a test). Which ends up in more Testing, and thus more time, less efficiency. I guess this is what testing is about : a bit more slowly, but surely. And thus you will gain time in the future.

Do these ideas make any sense?

Having said this, i am starting a project for which i don't have the time to learn and do all of this right now, so i will go with your method. Later i might try and make this project "safer". I should.

Thanks for the advice on how to use PERL5LIB, lib and perl -I, too. It's exactly what i needed to understand =o) Now i'll need to experience it. I guess i'll come back to read your message when i'm doubting about which method is more appropriate.