Repository navigation
Programmatically check/enforce "agreed upon" style and conventions #6
Description
Activity
- changed the title
[-]Programmatically check enforce "agreed upon" style and conventions[/-][+]Programmatically check/enforce "agreed upon" style and conventions[/+]on Jan 12, 2016 Not wanting to blow my own horn, but FORD might be useful for this. What
we could do is use it as a library to build up its internal model of the
code and then write another program with rules to analyze names etc. of
different entities. This would not be the only analysis we'd want to do,
as it would not be able to analyze things like line length and
indentation (that information is lost early on in its processing), but
it could be a good start.On 12/01/16 12:23, Izaak Beekman wrote:
AKA make a "linter" or style audit tool.
It would be great to be able to have a tool to check conformance of
program source code to a set of style guides, as well as check for
dubious constructs. Ideally such a tool would have the ability to
include or exclude individual rules, and print warnings showing the
offending constructs, their line number, and which file they are found
in, along with an exit status to indicate success (no offenses) or
failure. Additionally it would be wonderful to be able to add custom
rules in a simple syntax, to allow projects that don't agree with the
set of common guidelines we come up with to add their own.Obviously, this is a very long term goal, and to a degree I may be
putting the cart before the horse here: First we need to come to a
consensus, or at least a compromise, of what the rules of style are,
before we start thinking of ways to detect whether or not they are
being violated.Additionally we're going to need to consider how to implement such a
tool: Do we need a full parser for the entire Fortran language, or
could we do something more quick and dirty based on regular
expressions etc.Also, if we decide to create such a tool what language etc. should we
use? We could use Fortran itself, however, even with some nice recent
improvements like deferred length characters and reallocation on
assignment, other languages, like Python, might be quicker and easier
to implement such a tool.—
Reply to this email directly or view it on GitHub
#6.Chris MacMackin
cmacmackin.github.io http://cmacmackin.github.io@cmacmackin FORD is an incredibly useful and powerful tool. Using it as a library, or extracting logic from it could be a great way to bootstrap a linter/style audit tool.
I'd have to think about it a bit more, but I think I'd prefer to fork
the useful parts of FORDs code rather than use it as a library. I'm not
sure that I'm willing to commit to maintaining an API for its internals.On 12/01/16 12:32, Izaak Beekman wrote:
@cmacmackin https://github.com/cmacmackin FORD is an /incredibly
useful and powerful/ tool. Using it as a library, or extracting logic
from it could be a great way to bootstrap a linter/style audit tool.—
Reply to this email directly or view it on GitHub
#6 (comment).Chris MacMackin
cmacmackin.github.io http://cmacmackin.github.ioAKA make a "linter" or style audit tool.
You are into my mind, confess! I am almost sure to have suggested such a thing into google group CLF without obtaining any interests 😢
@cmacmackin
Yes, I was also thinking to FORD (not only as a linter, I will in the future grab your secrets for FoBiS...).However, I think @zbeekman is too futuristic: we have just started to discuss 😄
P.S. in only two posts I have learned a lot of slang:
putting the cart before the horse: in Italy we sayoxinstead ofhorse, maybe because Italy is slow and US fast...blow my own horn: wonderful.
@zbeekman I agree, I was just trying to teasing you 😄
I also vote for a Fortran linter (something sorely needed). If it's based on FORD, then all the better!
AKA make a "linter" or style audit tool.
It would be great to be able to have a tool to check conformance of program source code to a set of style guides, as well as check for dubious constructs. Ideally such a tool would have the ability to include or exclude individual rules, and print warnings showing the offending constructs, their line number, and which file they are found in, along with an exit status to indicate success (no offenses) or failure. Additionally it would be wonderful to be able to add custom rules in a simple syntax, to allow projects that don't agree with the set of common guidelines we come up with to add their own.
Obviously, this is a very long term goal, and to a degree I may be putting the cart before the horse here: First we need to come to a consensus, or at least a compromise, of what the rules of style are, before we start thinking of ways to detect whether or not they are being violated.
Additionally we're going to need to consider how to implement such a tool: Do we need a full parser for the entire Fortran language, or could we do something more quick and dirty based on regular expressions etc.
Also, if we decide to create such a tool what language etc. should we use? We could use Fortran itself, however, even with some nice recent improvements like deferred length characters and reallocation on assignment, other languages, like Python, might be quicker and easier to implement such a tool.