Hi,

I guess I am responsible for coining the term Spartan Programming, and for authoring the wikipages on the topic. My attention was drawn to this thread. I truly appreciate the comments, and would like to hear more of those - and get the discussion going.

Here is my response to some of the comments I saw here:

- Terse naming in in a sense an end, not a tool. That is, you should code in such a fashion that terse names make sense. Consider for example the code fragement: c.setSN(f.getSN()); used here.
Is c a good or a bad name? Well, it depends, not on the complexity fo the algorithm, but rather on the scope: if c is defined and used in a very small scope (say a handful of lines), with a few other similarly short scoped identifiers hanging around, then c is an ideal name.

If however, the scope is large, and there are many other names that the reader has to keep in mind, then c is a bad name. The cure I think is not in using a longer, more meaningful and much more verbose
name for this entity, but rather in refactoring that would make the code small enough so that c becomes an appropriate choice.

- There were some comments about foreach construct. I firmly believe that forach is the way to iterate, whenever possible, but
not beyond that limit.

- PHP can also be spartanized: I once run a huge project in which I was trying to semi-automatically spartanize a CMS program, using the number of conditional as the primary metric. The results were encouraging, but the whole project went down the drain due to a disk crash.

- Please note that the wiki offers many examples of Java classes written in the Spartan style. These are not perfect, but you may want to consider these in your discussion. Here are a number of links
(there are more):

http://ssdl-wiki.cs.technion.ac.il/wiki/index.php/Class_Position
(an implementation of a (line:column) pair

http://ssdl-wiki.cs.technion.ac.il/wiki/index.php/Class_Graph
(an implementation of a Graph data structure)

http://ssdl-wiki.cs.technion.ac.il/wiki/index.php/Class_DBC
(an implementation of Design by Contract)

http://ssdl-wiki.cs.technion.ac.il/wiki/index.php/Class_Defaults
(a useful micro abstraction)

Many more examples can be found by searching for the Class XXXX pattern in the wiki index.
http://ssdl-wiki.cs.technion.ac.il/wiki/index.php/Special:Allpages

----------------

Thanks for your attention, I would try to make myself available for more comments and discussion.

Yossi

Following the discussion, I completed the Java Spartan Programming example. The result, shown at http://ssdl-wiki.cs.technion.ac.il/wiki/index.php/SendAnEmail_case_study

demonstates why short, one variable names makes sense.

private static void sendEmail(final String from, final ListString to, final String subject, final String body,
final ListFile attachments) throws Throwable {
final Session s = Session.getInstance(new Properties());
final Message m = new MimeMessage(s);
setHeaders(m, from, to, subject);
setContent(m, body, attachments);
sendMessage(m, s);
}

private static void setHeaders(final Message m, final String from, final ListString to, final String subject) {
m.setSentDate(new Date());
m.setFrom(new InternetAddress(from));
for (final String t : to)
m.addRecipients(Message.RecipientType.TO, InternetAddress.parse(t, false));
m.setSubject(subject);
}

private static void setContent(final Message m, final String body, final ListFile attachments) throws MessagingException {
if (attachments.size() == 0) { // ''No attachments to send''
m.setText(body);
return;
}
// ''Generate a multi-part message''
final MimeBodyPart textPart = new MimeBodyPart();
textPart.setText(body);
final Multipart mp = new MimeMultipart();
mp.addBodyPart(textPart);
for (final File f : attachments)
mp.addBodyPart(makeBodyPart(f));
m.setContent(mp);
}

private static MimeBodyPart makeBodyPart(final File f) throws MessagingException {
final MimeBodyPart $ = new MimeBodyPart();
final FileDataSource fds = new FileDataSource(f);
$.setDataHandler(new DataHandler(fds));
$.setFileName(fds.getName());
return $;
}

private static void sendMessage(final Message m, final Session s) {
final Transport t = s.getTransport(smtp);
t.connect(smtpServer, port, userName, password);
t.sendMessage(m, m.getAllRecipients());
t.close();
}

Bill: You are very right. The C example is basic. It must be revised!
-------------------------------------------------------------

James A: As the author of the page on Spartan programming, I do not feel being treated too unfairly. To the contrary...
************************************
Further, what I would like to do is open the wiki for editing by
other people interested in the technique. If you are interested, please write to me (my address is not hard to find: look for Yossi Gil Technion at Google and it will give your all sorts of contact information.
------------------------------------------
----------------------------------------------------------------

RedGreen: I am not sure I agree with the criterion you offer: that the code is readable even to somone who does not know the language.
I suggest you examine the final code:
The main routine, sendEmail, has only six statements, which make the algorithm particularly clear.

final ListFile attachments) throws Throwable {
final Session s = Session.getInstance(new Properties());
final Message m = new MimeMessage(s);
setHeaders(m, from, to, subject);
setContent(m, body, attachments);
sendMessage(m, s);
----------------------------------
Paul Schirf: Liked your !me answer. And, I can understand why some people object to one letter names. Now, I wonder whether your sentiments are as negative towards the final version of the revised
sendEmail message, namely, http://ssdl-wiki.cs.technion.ac.il/wiki/index.php/SendAnEmail_case_study#Final_Result
------------------------------
Tirat: I would write the abs example as
int abs(int x) {
return x 0 ? x : -x;
}
That is, check first for positiveness (in accordance with the rule of
shortest branch first), and elminate the parenthesis.
---------------------------------------------------
T.E.D. : Would you like to help in revising the C example? Would you mind if I used your suggestions?

More comments:

* Terse naming refers mostly to variables. So in referring to the example, c.setFN(...), Spartan does not argue that the function is named setFN.

* The C example is not very convincing, I agree. Will try to find a more illustrative one.

* Most importantly, I invite anyone to examine the Spartant code samples (taken from a large, production application), to make more concrete comments.

Here is a meta-issue for everyone to consider. I tried reading most of the stuff written here, and noticed a couple of statements, which follow the following 3 parts syllogism:

(1) Programming practice X is good [bad], because it produces code of style Y.
(2) Style Y is good [ugly] code. For proof see part (3).
(3) I say style Y is good [bad].

The great fun in making such an argument is never shadowed by the futility of trying to convince anyone with it.

Is there an alternative? I am not sure. My attempt in making the case for Spartan programming was based on more or less agreed upon metrics, and then trying to optimize these.

The difficulty with my argument is that it is a universal truth that any one of these metrics, or any other metric for that matter, is that they can be used to ridicule the purpose they are set to serve.

There is a general agreement (I think) that in general, shorter code is better than longer code, all things being equal.

But, if you try to get the shortest possible program for any given task, you would quickly become a competitor of the obfuscated C code contest.

How does one quantify code quality? Is there a more or less objective method to asses quality?

Graham: I am of course familiar with statistical methods. I am not sure they can be used here: unlike many other fields of science, experiments are very difficult to conduct, and the interpretation is very subjective. As a reference point, consider application of statistical methods to determine whether a certain protocol is better than another in treating a particular disease. The design of such an experiment is not trivial, and there are companies which make fortune just by doing that. But, the problems in doing a software based experiment are much much worse - and any change to the fundamental variables will invalidate the results: change of programming language, programming environment, debugging task, debugger tool, programmer training, underlying code, etc. It would be nice if we could run experiments of this sort. I am not so sure this is possible - but I will check out the references you provide.

What I am looking for is a method, which obviously exists in other disciplines, of reaching some agreement, without the usual bickering.
Such methods must exist in fields such as law, humanities, and other, non exact, non empirical fields of science.

titrat: I am not sure I fully understand the implications of returning -0. Do you say it may be less efficient? Or do you say it may lead to wrong results on some machines?

To Paul Schirf: I am glad you liked the final version (again, I am not sure how we should go about quantifying liking...).

The point here, which I should probably have stressed better is the following. Terse names, that is one or two letter names, make more sense if the context is small. Consider for example identifying an individual person. Within the small family cycle, a one syllable nickname would do. In a classroom, you may need to use the first name spelled in full: Paul. When the individual is part of a larger audience, say, participants in a forum, you may need to write Paul Schirf, and if you need address this individual among all citizens of a large state, you may need to write: PaulSchirfMaleOfPalmSprings.

The point is the following: the smaller the scope, the shorter the name. Conversely, if you strive for short variable names, you will be gravitating towards smaller modules.

There is another point to make here (eventually I will add this to the wiki): in the course of decomposition, you often come up with small, yet general modules. These modules often make terse names even more necessary.

In the Paul Schirf example, suppose you have a module with code designed to serve as back door of an application, e.g., by testing if (user==Paul Schirf) { do lots and lots of special things }.

Now, in decomposing the body of the conditional, one may come up with a small sub module designed to send a birthday greeting by email to the individual. I would expect a signature of the sort of,
congratulate(Person p)
to that module. Conversely, if the same code was inlined into the main module, you would more inclined in using a verbose name for the user to congratulate, by writing e.g.,

User backDoorUser = ...;
Message congratulation = ....;
send(congratulation, backDoorUser)

The point here is that the strive towards general, non descriptive names, is stimulates and is satisfied by good modular decomposition.

PS.
Others here may suggest using congratulate(Person person) as signature for the submodule, i.e., naming the parameter person rather than p. I am interested in understanding better what makes people prefer the more verbose version in such a case.

Yossi

Interesting that people here mention C++. I first used the term Spratan Programming in the context of C++ - and even gave a tutorial on the method in the TOOLS USA 1996 conference.

(believe it or not, there is an acronym behind the term)

The Wiki page was written to help my amazing students train with the method.