Programming Mathematica in plaintext, i.e. no formatting, non-notebook

Yes, plain-text programming, as you call it, can be done in Mathematica. It is often used for developing packages (.m files). Try searching this site with the phrase "package development" to get more info.

There is even a built-in working environment supporting package development. It has its own style sheet in which code-form cells (plain-text initialization cells) replace input-form cells as the default cell style. It also provides a few of the traditional IDE tools such as a Run button. To try it, or at least look at it, choose Package from the File > New menu. However, when developing a package, I still keep a normal notebook open to act as a test harness.

This brings me to my final point. Mathematica differs from C++ and similar languages in that it is an interpreted rather than a compiled language. This means you can break out of the code-compile-test cycle and adopt a very fine-grained incremental style with lots of interaction and micro-testing. An interpreter has the advantage of being able to serve a highly interactive debugger. If you have no previous experience with interpreted languages, you should definitely try working with Mathematica interactively. It allows you to develop a program in very small increments, each of which is individually tested, so that you have tested, working code at every stage of your program's development. Of course, this requires acquiring a somewhat different mind-set, but I have found it a very satisfying, indeed addictive, way of programming.

I like to save my files in "plaintext" for 3 reasons:

• Can use SVN to have embedded version information, look at diffs from coauthors, etc.
• Don't mix the code itself with the output of the code, which also makes interacting with coauthors difficult and is unclear what has been run and what hasn't.
• Be able to run the files commandline on a cluster if required (though not debug/program on it)

But none of those are really "programming" in plain-text. The Notebook environment is far too powerful to ignore. So here is how I work:

• Store your files as .m package files. This means they are plaintext for the purposes described above and can be run commandline on a cluster as required.
• Load and edit the .m files in the normal FrontEnd. They are not all that different from working with the than Notebook files themselves
  • Different sections of your code can be separated by 2 newlines
  • In particular, you can Shift-Enter run only 1 section of a time of your code (i.e. those separated by newlines). If you run the whole package, then it will nicely display the output from the different sections like different sections in a notebook file.
  • The only caveat is that if you type in certain things into your code, they will display in the FullForm upon opening the package (e.g. subscripts typed as $a_l$ become Subscript[a,l] after reopening the file). However, greek letters seem to display properly when opening the file, and you shouldn't use subscripts in variable names anyways (see Displaying index as subscript on output: e.g. C[i] -> C_i with Notation[...] or Interpretation[..]? for how to look like subscripts in the display )
  • When you save the .m, you will only be saving the input - which is what I like. If you have a very long calculation that you don't want to lose, you can save the state and load it using something like: DumpSave["myfile.mx", "Global"];` This way you can separate the calculation of complicated things (which could be run commandline if required) from the analysis, which doesn't have to be.
• Finally, when you are programming, open up a blank notebook file to act as sort of an interpretive window. That way you can test things out and only copy code over to the .m file as required

This question is related to What are the advantages of using .nb rather than .m files?
That question details some of the differences you will face in using a plaintext format.

If you are merely seeking manual code formatting rather than having Mathematica reflow your input you can use the Code cell style, or a customized version (e.g. without being Initialization cells) using style sheets. See Automatic Text Adjustment.