Comfortable source file size?
John Seal
decide to break it into smaller chunks? I've got a 600-line file that's
starting to feel unwieldy in Vim, the editor I generally use. I'm just
curious what sort of guidelines other people go by.
Bud Beacham
"John Seal" <se...@indy.raytheon.com> wrote in message
news:1M0Bb.367$b77...@dfw-service2.ext.raytheon.com...
I also use VIM on Linux. I haven't yet reached what I consider an
uncomfortable level in so far as program size. One program has 1,457 lines
(70K) and another has 1,529 lines (77K). Since I use a lot of little
procedures to do virtually everything it is easy to read and follow. The
biggest problem with the program size is that if I print it without using
both sides of the paper they are difficult to staple.
Bud Beacham
Cameron Laird
I just picked up the first big system on which I happen to be working.
The line counts of individual *.tcl sources follow. There's no
interesting live controversy among the development team about making
things bigger or smaller.
5
12
14
17
20
21
22
26
27
31
34
34
37
42
43
44
44
48
48
50
50
54
62
65
66
70
71
71
71
75
76
76
79
82
83
83
83
89
89
89
92
92
99
100
100
102
108
110
111
112
115
116
119
120
121
123
124
134
135
138
138
146
151
152
154
155
160
163
164
176
184
185
186
189
190
192
194
198
198
205
207
209
210
220
221
221
223
223
225
226
227
232
237
237
238
239
241
257
258
265
274
274
283
284
290
291
292
298
298
302
303
303
308
312
314
314
326
332
342
345
349
353
354
354
360
366
379
380
388
393
405
408
420
426
426
436
439
446
451
453
455
457
458
469
472
503
506
507
517
520
523
533
544
548
563
571
580
581
622
629
657
664
668
726
738
752
773
778
787
827
856
866
892
895
932
957
973
984
994
1012
1015
1023
1080
1128
1135
1142
1147
1179
1241
1246
1249
1283
1329
1374
1389
1408
1460
1555
1581
1622
1626
1674
1696
1817
1890
1902
1934
2004
2172
2251
2331
2441
3021
3730
3794
5485
5506
6051
15616
16636
It occurs to me that an ENTIRELY different question might be the
one you're asking: when I begin with a little single-source-file
application, at what point do I feel an urge to resegment? There's
a lot to say on that; let's return to it, if that's what you're
really after.
--
Cameron Laird <cla...@phaseit.net>
Business: http://www.Phaseit.net
Volker Hetzer
"John Seal" <se...@indy.raytheon.com> schrieb im Newsbeitrag news:1M0Bb.367$b77...@dfw-service2.ext.raytheon.com...
stuff together I have no problem with lots of small files.
Greetings!
Volker
Volker Hetzer
"Cameron Laird" <cla...@lairds.com> schrieb im Newsbeitrag news:vt97o5s...@corp.supernews.com...
> It occurs to me that an ENTIRELY different question might be the
> one you're asking: when I begin with a little single-source-file
> application, at what point do I feel an urge to resegment? There's
> a lot to say on that; let's return to it, if that's what you're
> really after.
Beginning contains the # \-stuff and declarations for the global variables,
Gui, well, the Widget stuff and functions to manipulate the appearance of
them (like disabling or enabling menus) and Main evaluates the command line
and does the initialisation.
Lots of Greetings!
Volker
John Seal
> It occurs to me that an ENTIRELY different question might be the
> one you're asking: when I begin with a little single-source-file
> application, at what point do I feel an urge to resegment? There's
> a lot to say on that; let's return to it, if that's what you're
> really after.
That actually is the question I'm asking. I guess you have to read
between the lines; when I said "before you decide to break it into
smaller chunks", that implies that it started small, then grew to the
point where you were uncomfortable. That's exactly what happened in
this case. I already have one separate 300-line file that I source, but
that's because I'm reusing it from another project. The new file has
grown to 600 lines, and there are a couple of easily identifiable chunks
that I could separate out into separately sourced files.
Looking at your ad-hoc files size numbers, all I can say is that, given
the choice between 100 20-line files, 10 200-line files, or 1 2000-line
file, I'd pick the medium or large file sizes. My current "big
project", the one I get paid for, has 15K lines in 46 files, so
apparently a 600-line file is about double my comfort limit.
Volker Hetzer
"John Seal" <se...@indy.raytheon.com> schrieb im Newsbeitrag news:2u1Bb.368$b77...@dfw-service2.ext.raytheon.com...
That's exactly what happened in
> this case. I already have one separate 300-line file that I source, but
> that's because I'm reusing it from another project. The new file has
> grown to 600 lines, and there are a couple of easily identifiable chunks
> that I could separate out into separately sourced files.
a big case for make-based development even with Tcl. I've been doing
this since I learned Tcl and it always worked great for me:
SRC:=A.tcl B.tcl C.tcl
MYEXENAME:=MyExecutable
tst: tstinstall
./$(MYEXENAME) -a -b -c
tstinstall: /tmp/MyApp/bin/$(MYEXENAME)
echo "" >$@
install: /usr/local/bin/$(MYEXENAME)
echo "" >$@
/usr/local/bin/%:%
cp $< $@
tstinstall: /tmp/MyApp/bin/%:%
cp $< $@
$(MYEXENAME): $(SRC)
cat $(SRC) > $@
And that's it. Obvioulsy you can extend the makefile to automatically
install packages or run pkgMkIndex.
Then you type "make" and watch the program being assembled,
installed and run.
If you want to install in the "release" directory, run "make install".
Sourcing files is IMHO messy.
Lots of Greetings!
Volker
Bob Techentin
> What is the biggest source file you're comfortable with, before you
> decide to break it into smaller chunks?
My favorite editor (emacs) (and many others) don't have a problem with
a couple of thousand source lines. But I have a little trouble
navigating when they get to be more than a few hundred lines.
Of more concern to me is that CVS is tracking changes on a per-file
basis. If your application is in several files, you can just "see"
stable and unstable parts of the code in the revision histories. And
its easier to see branches, bug fixes, and support multiple
developers.
So I usually just try to put one "thing" in a single source file.
When I was writing "C", that thing was a function. When I started
writing OO, it was an object. A small GUI might be one thing, but if
it gets large and complicated, I might split it up into several files.
Good luck,
Bob
--
Bob Techentin techenti...@NOSPAMmayo.edu
Mayo Foundation (507) 538-5495
200 First St. SW FAX (507) 284-9171
Rochester MN, 55901 USA http://www.mayo.edu/sppdg/
ulis
At 1,000 I feel uncomfortable.
At 2,500 I break the text.
ulis
Victor Wagner
: What is the biggest source file you're comfortable with, before you
: starting to feel unwieldy in Vim, the editor I generally use. I'm just
Learn how to do folding in vim. With folding I had no trouble to handle
several thousands of lines in perl (of cource half of them were POD
documentation) and Tcl is a bit less terse than Perl.
Unfortunately, I don't think that there is default Tcl folding method in
the vim distribution. Someone have to write one.
: curious what sort of guidelines other people go by.
--
Windows without the X is like making love without a partner.
-- MaDsen Wikholm, mwik...@at8.abo.fi
John Seal
> My favorite editor (emacs) (and many others) don't have a problem with
> a couple of thousand source lines. But I have a little trouble
> navigating when they get to be more than a few hundred lines.
Oh yeah, the problem is entirely with the cognitive burden on me to keep
it all straight.
Once upon a time I used Alpha for my Tcl programming. I had a function
that would automatically build a "procedure documentation" comment from
the [proc] line that defined it. I generally liked Alpha, but it seemed
like old stuff broke with every new release, and I just gave up trying
to deal with it. In a previous life as a Lisp programmer I used emacs.
The trouble with most editors, vi and emacs included, is that they are
definitely "use it or lose it". One editor I really like that doesn't
seem to be available on Mac OS X is the one integrated with TkDesk.
I had an interesting experience in the evolution of my "big project",
the one with 15K lines in 46 files. The GUI is multi-paned, and the
code was initially split up with a file for each pane, plus one for each
server or client, plus some for broad functional areas like the API or
the GPIB interface. But for a major rev I found myself repeatedly
visiting just certain parts of about six different files, parts that
together defined the "behavior" of the system. So I culled out those
sections of code and put them in a new file, behavior.tcl, so they were
all conveniently located together. I just checked... it's 584 lines,
yet another indication that my personal comfort limit is 300-600 lines.
Jeff Hobbs
> Bob Techentin wrote:
>
>> My favorite editor (emacs) (and many others) don't have a problem with
>> a couple of thousand source lines. But I have a little trouble
>> navigating when they get to be more than a few hundred lines.
>
>
> Oh yeah, the problem is entirely with the cognitive burden on me to keep
> it all straight.
>
> Once upon a time I used Alpha for my Tcl programming. I had a function
> that would automatically build a "procedure documentation" comment from
> the [proc] line that defined it. I generally liked Alpha, but it seemed
If you would like, I have a set of extended Tcl elisp macros
for things like Tcl style guide procs, file headers and the
like that I have had for years.
--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos
Jeff Hobbs
It isn't really what you personally are comfortable with than
what is a comfortable, *maintainable* size over time, no?
I have source files like tkcon that reaches near 8K LOC, and I
know most of that code rather intimately, having developed it
over years. However, I wouldn't inflict that on anyone, and
have actually refactored it before for general use (the console
megawidget).
The size of the file should try to be constrained within 1K LOC,
but it depends more on the functionality really. I can have
lots of files with 200-300 lines each, and they each deal with
a specific 'area', like color management, prefs management (or
just the prefs for colors ... depends on size), etc.
Better editors let you handle this in both ways. For example,
Komodo has both code folding, built-in macros for jumping from
proc to proc, and related features for making large files
"smaller". It also has full project management, so you can
break things into multiple files and still get a good overview
of everything.
Again, I think the most important thing is that when you break
down into parts, you do it by functional components. Don't set
super-hard limits. Some files can get large, but that may just
be the nature of what's in there.
bryan schofield
I'd be interested, Jeff.
-- bryan
Jeff Hobbs
>> If you would like, I have a set of extended Tcl elisp macros
>> for things like Tcl style guide procs, file headers and the
>> like that I have had for years.
I think these are all the relevant bits:
(setq tcl-default-application "tclsh")
(add-hook 'tcl-mode-hook
'(lambda ()
;; Yes, this really does improve debugging
(font-lock-mode 1)
(setq show-trailing-whitespace 1)
(define-key tcl-mode-map "\C-cf" 'tcl-stub-file)
(define-key tcl-mode-map "\C-c\C-f" 'tcl-stub-file-exec)
(define-key tcl-mode-map "\C-cp" 'tcl-stub-proc)
(define-key tcl-mode-map "\C-cn" 'tcl-stub-namespace)
(define-key tcl-mode-map "\C-c\C-p" 'tcl-stub-pkgindex)
))
;; <Control-c><Control-f>
;; Create the magic #! headers for a Tcl file
;; This will always insert at the top, but will do nothing
;; if the file already has a #! header
(defun tcl-stub-file-exec ()
"Inserts proper headers for an executable tcl file."
(interactive)
(beginning-of-buffer)
;; if it already appears to have the #!, just stop
(if (looking-at "^#!")
()
(progn
(insert "#!/bin/sh\n"
"# The next line is executed by /bin/sh, but not tcl \\\n"
"exec " tcl-default-application " \"$0\" ${1+\"$@\"}\n\n")
)))
;; <Control-c><f>
;; Create the file headers as per the style guide recommendations
;; This queries for a package name and version and insert the code
;; for package provision and namespace (thus Tcl8+ oriented)
(defun tcl-stub-file (pkgname pkgversion)
"Inserts proper headers in a Tcl file."
(interactive "sPackage Name: \nsPackage Version: ")
(beginning-of-buffer)
(if (looking-at "^#!")
;; If the file begins with "#!" (exec magic)
;; move forward to first empty line to avoid messing with it.
(search-forward "\n\n" (point-max) t)
)
(insert "# " (file-name-nondirectory buffer-file-name) " --\n#\n"
"#\tThis file implements package " pkgname ", which ...\n"
"#\n# Copyright (c) " copyright-current-year " " user-full-name "\n#\n"
"# See the file \"license.terms\" for information on usage and\n"
"# redistribution of this file, and for a DISCLAIMER OF ALL WARRANTIES.\n"
"#\n"
"# RCS: @(#) $Id$ \n\n"
"#package require NAME VERSION\n"
"package provide " pkgname " " pkgversion
"\n\nnamespace eval " pkgname " {;\n"
"#namespace export -clear *\n"
"\n\n}; # end of namespace " pkgname "\n")
(search-backward "\n};")
)
;; <Control-c><p>
;; Insert the stub headers for a proc with the style guide format
;; Queries for procedure name and args
(defun tcl-stub-proc (procname argnames)
"creates proper headers for a tcl proc"
(interactive "sProcedure Name: \nsArguments: ")
(let ((start (point)))
(insert "# " procname " --\n"
"#\n# ADD COMMENTS HERE\n"
"#\n# Arguments:\n"
"# args\tcomments\n"
"# Results:\n# Returns ...\n#\n"
"proc " procname " {" argnames "} {\n\n}\n")
(indent-region start (point) (tcl-calculate-indentation start))
;; move to body of proc
;; maybe should move to ADD to encourage commenting from the start
(search-backward "\n}")
))
;; <Control-c><Control-p>
;; Inserts a package ifneeded command, meant for pkgIndex.tcl
;; Queries for package name, version, tcl file and procedure names of
;; the package
(defun tcl-stub-pkgindex (pkgname pkgversion tclfile procnames)
"creates package ifneeded stub line proper for pkgIndex.tcl file"
(interactive "sPackage Name: \nsPackage Version: \nFTcl File: \nsProcedures: ")
(let ((start (point)))
(insert "package ifneeded " pkgname " " pkgversion
" [list tclPkgSetup $dir " pkgname " " pkgversion
" {\n {" (file-name-nondirectory tclfile)
" source {\n\t" procnames "\n}}}]\n"
)
(search-backward "\n}")
))
;; <Control-c><n>
;; Creates stub namespace headers
;; Queries for namespace name
(defun tcl-stub-namespace (namespace)
"creates proper headers for a tcl namespace"
(interactive "sNamespace Name: ")
(let ((start (point)))
(insert "# Namespace " namespace " --\n"
"#\n# ADD COMMENTS HERE\n#\n"
"namespace eval " namespace " {;\n"
"#namespace export -clear *\n"
"\n\n}; # end of nameespace " namespace "\n")
(indent-region start (point) (tcl-calculate-indentation start))
(search-backward "\n};")
))
(defun tcl-mode-customize ()
(auto-fill-mode 1)
(setq fill-column 79)
; This is "^C^C" for comment-region
(define-key tcl-mode-map " " 'comment-region)
(define-key tcl-mode-map [C-next] 'forward-tcl-definition)
(define-key tcl-mode-map [C-prior] 'backward-tcl-definition)
(define-key tcl-mode-map [menu-bar tcl-mode insert-header]
'("Insert Header" . insert-header))
(define-key tcl-mode-map [menu-bar tcl-mode insert-function]
'("Insert Function" . insert-function))
(define-key tcl-mode-map [menu-bar c core-headers]
'("Use Tcl Core Header Templates" . core-headers))
(define-key tcl-mode-map [menu-bar c scriptics-headers]
'("Use Scriptics Header Templates" . scriptics-headers))
)
(add-hook 'tcl-mode-hook 'tcl-mode-customize)
(defun forward-tcl-definition ()
"Move forward to the next procedure definition."
(interactive)
(forward-char)
(re-search-forward "proc ")
(goto-char (match-beginning 0))
(recenter '(4)))
(defun backward-tcl-definition ()
"Move backward to the previous procedure definition."
(interactive)
(re-search-backward "proc ")
(goto-char (match-beginning 0))
(recenter '(4)))
Michael A. Cleverly
> If you would like, I have a set of extended Tcl elisp macros
> for things like Tcl style guide procs, file headers and the
> like that I have had for years.
That sounds interesting enough to make me almost tempted to give emacs
another try (I've tried to switch to emacs a couple of times in my life,
but so far I've always ended up going back to vi :-).
Michael
se...@fishpool.com
Matter of taste, mostly, but when you go well over 1000 lines I think
it may be good to consider whether there may be good chunks that can
be separated together.
I think the most important is that, however you split something up, it
should make sense. Things that are relevant to each other should go together.
If they have little to do with another group, they probably shouldn't be
in the same file. Perhaps it helps to think in areas of responsibility.
Bob Techentin
> >> If you would like, I have a set of extended Tcl elisp macros
> >> for things like Tcl style guide procs, file headers and the
> >> like that I have had for years.
Thanks Jeff. Those are pretty nice.
For some reason, my NT Emacs 21.3 didn't understand
'copyright-current-year ', but I was able to substitute
(format-time-string "%Y" (current-time))
A.Mucha
>
> Unfortunately, I don't think that there is default Tcl folding method in
> the vim distribution. Someone have to write one.
the standard folding marks in vim contain braces.
It is much better to use folding marks without braces!
First I wanted to use <<<, but the first
conflict in cvs showed that this was not a wise selection 8-)
So I came up with #<-< and #>->.
in /usr/share/vim/current/ftplugin/ I wrote the followin in tcl.vim
" This is file $VIMRUNTIME/ftplugin/tcl.vim
" Vim FileType plugin for Tcl/Tk-Files adding folding
" Last Change: 22.04.2003
" Maintainer: Albrecht Mucha <A.Mucha@_____.de>
" Join the two lines _______@mdtec.__
"
source $VIMRUNTIME/ftplugin/vim.vim
:setlocal fmr=<-<,>-> fdm=marker cms=#%s
" this sets the folding marks to <-< and >->
function! MyFoldText()
let line = getline(v:foldstart+1)
let sub = substitute(line, '/\*\|\*/\|{{{\d\=', '', 'g')
return v:folddashes . sub
endfunction
set foldtext=MyFoldText()
" this shows the line after the foldmark as text
map <F5> :call append(line(".")-1, "\# <-<" . (foldlevel(line(".")) + 1))
map <F6> :call append(line("."), "\# >->")
" maps to help insert foldmarks. Use: go to end of proc on } and press F6 % F5
" ############################################
" end of tcl.vim
happy christmas-time to all
Albrecht Mucha
D 31162 Bad Salzdetfurth
Glenn Jackman
> the standard folding marks in vim contain braces.
> It is much better to use folding marks without braces!
You might want to add this info to http://wiki.tcl.tk/vim
--
Glenn Jackman
NCF Sysadmin
gle...@ncf.ca
John Seal
<Pine.LNX.4.44.031208...@gibraltar.cleverly.com>,
"Michael A. Cleverly" <mic...@cleverly.com> wrote:
> almost tempted to give emacs another try
emacs: escape-meta-alt-control-shift
It's right up there with TECO on the obtuseness scale. I used an emacs
work-alike in my Lisp days, call gmacs.
bryan schofield
true... emacs is a bit ... different, but I've used 8 or 10 hours a day
for the last 4 years and can definately say it grows on you. Emacs has
become by desktop environment. I do everything from it, and I've just
about forgotten how to use a mouse :-P. There is always vi-emulation
mode for emacs (Viper?) if you are a big vi fan.
Luciano ES
I determine the first steps and save it as begin.tcl
Then write all procs, separated by a line, like
# ---- OPEN FILE --------------------------------------------
# -----------------------------------------------------------
and save it as procs.tcl
Then I make the widgets and save it as gui.tcl
Then I write all bindings and save it as bind.tcl
Finally, I write aplication.tcl :
source begin.tcl
source procs.tcl
source gui.tcl
source bind.tcl
any other necessary code
and run!
Just one among many possible methods. I also have made an application
with each proc in a separate file:
source proc_open.tcl
source proc_save.tcl
source proc_help.tcl
...etc. But it was more work.
--
Luciano ES
WARNING: fake address on reply!
<yhp-gpyre ng OenmvyvnaGenafyngvba.arg> (ROT 13)
Santos, SP - Brasil