spartanrefactoring / spartan Goto Github PK

With regards to this paragraph.

Thus, there are four components to the spartaniza-
tion process: (i) structural, (ii) nominal, (iii) cleanup,
and, (iv) modular. Current technology can automate
all but the last component; automation of method ex-
traction requires more research, paying attention to cur-
rent state of the art [?].

I found these:

~\cite{Griswold:Chen:Morison:Bowdidge:1998,
Holmes:Murphy:2005
}.

but I am not sure that they are good.

I would remove it. Now there are a lot of example that can well scare the readers :)

I was not able to find it so far.
I found the first one in dblp at this address:
http://dblp.uni-trier.de/pers/hd/l/Lalouche:Gal
There is nothing at his web page (in the Technion website), or at his Linkedin profile.
It is not cited in "When the metrics mean nothing" (at least in my pdf).
Also in your profile on dblp there is not a second paper.
Do you have any clue? Keywords, title, conference venues, journal, etc?

Which term is better to use throughout the paper?
Should I better use code style (or styling) or code conventions?

For space constraints, we maybe need to shrink a bit the technique section - that is, perhaps, already significantly large btw. I already gathered the techniques in separate subsections, but there are some for which I do not know if we have to mention them or not (or if their are already mentioned in the present paragraphs - I got confused by some of the notes).

1. Move everything from the "Spartanizer" project.
2. Do "mvn package"
3. Manually copy jars to the Spartanizer project

Sort out the list of nanos and candidates.
Make a short list of everything that can be written as fluent API. But, do not write a fluent API for this.
Do this in LaTeX.

Speaking of style, how we should deal with urls? Should I place them on the references or on footnotes?