About 3 decades ago, one of my mentors offered the thought that a really
practical metric for software maintainability is the percentage of fixes
and enhancements that require editing only one region of one file. As he
put it: "Visit your programmers' cubicles and find out how many files have
to be changed for each of those little yellow stickies on the wall."
Hopefully no one is still tracking issues with stickies on the wall these
days, but you get the idea.
Lately I've been working solo on an control systems app (now partially
ported to Go) where each change seems to require hitting at least three
files not counting adding unit tests. I started wishing Go could support
multiple package declarations within the same file so I could write things
like:
package common
type someStruct struct {
}
package client
func someCommand(){
}
package server
func someCommandHandler() {
}
// etc
I realize that's unlikely to happen, so I did the next best thing and wrote
a little file splitter. It's used like this:
// FTEE common.go
type someStruct struct {
}
// FTEE client.go
func someCommand(){
}
// FTEE server.go
func someCommandHandler() {
}
// etc
It also support multiple output targets like 'FTEE foo,bar baz.grp ...'
It seems to be working pretty well so I thought I'd share it.
https://github.com/Michael-F-Ellis/ftee
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
