Tag Info

Hot answers tagged

80

The only advantage I can think of for inline tests would be reducing the number of files to be written. With modern IDEs this really isn't that big a deal. There are, however, a number of obvious drawbacks to inline testing: It violates separation of concerns. This may be debatable, but to me testing functionality is a different responsibility than ...


34

I can think of some: Readability. Interspersing "real" code and tests will make it harder to read the real code. Code bloat. Mixing "real" code and test code into the same files / classes / whatever is likely to result in larger compiled files, etc. This is particularly important for languages with late binding. You may not want your customers / clients ...


23

I first saw it in a book of Knuth's writings, and thought it looked neat. Then I tried to use the literary programming display to comprehend what was going on in the program, and found it harder than it looked. It may have been that I was too used to going through program listings, but it seemed confusing. Then I looked at the source code, and that turned ...


12

I would blame the network effect. For other people to edit your code and documentation, they must be able to understand it. This pushes people away from something like cweb/noweb, because using them would require you to learn TeX and the program-specific syntax on top of the programming language you are using for the project. This can be seen as a huge ...


12

Literate programming and the semantic web are both concerned with meaning. The semantic web seeks to make the Internet more intelligent by adding what I call "conceptual metadata" (i.e. topical information) to web pages. Pages so annotated become more than just randomly linked bits of text; they become conceptual frameworks of information (i.e. ...


11

Actually, you can think of Design By Contract as doing this. The problem is most programming languages don't let you write code like this :( It's very easy to test for preconditions by hand, but the post conditions are a real challenge without changing the way you write code (a huge negative IMO). Michael Feathers has a presentation about this and this ...


11

For many of the same reasons that you try to avoid tight coupling between classes in your code, it's also a good idea to avoid unnecessary coupling between tests and code. Creation: Tests and code may be written at different times, by different people. Control: If tests are used to specify requirements, you'd certainly want them to be subject to different ...


10

Here are some additional reasons I can think of: having tests in a separate library makes it easier to link only that library against your testing framework, and not your production code (this could be avoided by some preprocessor, but why to build such a thing when the easier solution is to write the tests in a separate place) tests of a function, a ...


9

This would yield automatic insertion of the code, instead of a separate function compilation and subsequent requirement of an inter-procedural compilation optimization step to obtain the equivalent speed This is irrelevant. Has been for decades. You can remove it from the question, since it makes no sense with modern compilers to subvert their ...


4

Coders write code not English. Coders don't like writing documentation because it doesn't help the code run. Coders aren't good at writing documentation because its a poor medium to express their ideas. Literate programming seems to be the idea of taking documentation to the next level where the code is more of an after-thought. Maybe it would work, but ...


4

If tests were inline, it would be necessary to remove the code you need for testing when you ship the product to your customer. So an extra place where you store your tests simply separates between the code you need and the code your customer needs.


3

This idea simply amounts to a "Self_Test" method within the context of an object-based or object-oriented design. If using a compiled object-based language like Ada, all the self-test code will be marked by the compiler as unused (never invoked) during the production compilation, and therefore it will all be optimized away - none of it will appear in the ...


3

Both concepts appear to target the point where human reading meets computer execution. In literate programming, human readable part is represented by the idea of writing programs like in an ordinary human language, much like the text of an essay. Respective part in semantic web is that it targets human-readable web pages. Computer execution aspect in ...


3

One thing I discovered when I had my fling with literate programming in the 90s was that it attracted very passionate people who wanted to do Exactly The Right Thing - and that involved writing their own literate programming system because no existing one was good enough for them. noweb was a good attempt to cut that off by providing a good-enough least ...


2

In my humble opinions, many companies have a culture who is the opposite to the objectives of Literate Programming: they want faster results (they only cry about quality when the app is in production). In my own experience, my bosses had refuse to understand that faster results doesn't mean "a program runnable the day after I asking for." For them, if a ...


2

The most important aspect of literate programming (or even just good commenting) for me is not so much that it provides documentation, but rather it states the intent of the programmer. In knowing the stated intent, you can immediately judge whether or not the code following it really does what it should. Without intent, you have to begin with the assumption ...


2

While rather new to the concept of litterate programming myself (and it's therefore likely that I'm missing the boat entirely), it seems very much to line up with the concept of a DSL. The idea behind a DSL is to distill down a domain of problems into a simple, natural-language-oriented grammar that can be used to built algorithms for solving those ...


2

We use inline tests with our Perl code. There's a module, Test::Inline, that generates test files from the inline code. I'm not particularly good at organizing my tests, and have found them easier and more likely to be maintained when inlined. Responding to a couple of the concerns raised: The inlined tests are written in POD sections, so they're not ...


1

This is in response to a large number of comments suggesting that inline tests are not done because it's difficult to impossible to remove the test code from release builds. This is untrue. Almost all compilers and assemblers support this already, with compiled languages, such as C, C++, C#, this is done with what are called compiler directives. In the case ...


1

Erlang 2 does actually support inline tests. Any boolean expression in the code which is not used (e.g. assigned to a variable or passed) is automatically treated as a test and evaluated by the compiler; if the expression is false, the code doesn't compile.


1

There are 2 aspects of literate programming that I do wish were incorporated into mainstream programming -- embedded imagery (e.g., design diagrams) and pointers to previous and alternate attempts (e.g., "The reason it's like this is because I tried this other way and it didn't work because ..."). Both of those aspects can be handled with doc-comments and ...


1

Because the logic of programs does not work the same as we speak. A program has a well specified flow, and conditions, and loops. After having coding at lot, I THINK in these terms. My brain transforms problems into the target domain of executable code. And it is much more efficient for me to write this down in a usually programming language, than having ...



Only top voted, non community-wiki answers of a minimum length are eligible