Just ranting about sub-contractors......
DanS
This is in regards to the telnet app I decided (had to) to rewrite......
(I had decided to redo the UI from scratch, and then *adapt* parts of his
code to it.)
Not only is his spaghetti code written with no indents, REMs, or anything
like that........
........but he also left control names at their default.........
........there's a million text controls named Text11, Text12, Text13,
etc..........
........option controls named Option4, Option5, etc..........
........and then there's individual Frames, and Frames that are control
arrays, and individual labels, and labels that are control arrays.
........and when you replace a control with a different type of control,
change EVERYTHING, not just the control itself !!!!......
For instance, he was using Label for command buttons...I don't know, I
guess he wanted the flat look.....but when I reviewed the app two months
ago, I told him to replace the label-buttons with *real* buttons, he
did....but left the names as lblXXXXXX, and used the existing event names
too, a (several) command button is named lblXXXXX and it's event is named
lblXXXXX_Click !!!!!
Sorry.....just ranting.....
(I needed to b*tch somewhere....the wife just doesn't understand.....she
can nod her head in agreement, but....)
C. Kevin Provance
I feel your pain brother. :(
"DanS" <t.h.i.s....@r.o.a.d.r.u.n.n.e.r.c.o.m> wrote in message
news:Xns9CF570C25431Bth...@216.196.97.131...
Larry Serflaten
"DanS" <t.h.i.s....@r.o.a.d.r.u.n.n.e.r.c.o.m> wrote
> Who taught that sub-contractor to program ???!?!!!
How about spending an hour or two writing a .frm file filter.
One that lists the old name and lets you give it a new name,
which then replaces every occurance of that old name.
You could show the scope, type, and name, and let the
user enter a new name. Working with the file you could
change the control name, and its events, plus everywhere
else it is used....
That might help this project, and if you have some time
later, you could add proper indenting to the mix. It would
be a useful tool for any project your working on.
LFS
C. Kevin Provance
wonder if MZTools has something that would help.
--
2025
If you do not believe in time travel,
your beliefs are about to be tempered.
http://www.facebook.com/group.php?gid=43606237254
"Larry Serflaten" <serf...@usinternet.com> wrote in message
news:uNBXE7Kj...@TK2MSFTNGP02.phx.gbl...
Tony Toews [MVP]
DanS <t.h.i.s....@r.o.a.d.r.u.n.n.e.r.c.o.m> wrote:
>(I needed to b*tch somewhere....the wife just doesn't understand.....she
>can nod her head in agreement, but....)
That's frigging incredible. <shudder> If anything my sub, function
and variable names are too long.
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
DanS
@TK2MSFTNGP02.phx.gbl:
>
> "DanS" <t.h.i.s....@r.o.a.d.r.u.n.n.e.r.c.o.m> wrote
>> Who taught that sub-contractor to program ???!?!!!
>
> How about spending an hour or two writing a .frm file filter.
> One that lists the old name and lets you give it a new name,
> which then replaces every occurance of that old name.
I've already designed the new UI....with more properly named controls.
Well, since the code is horrible too, I'm rewriting that from scratch using
the original (bad) project as a guide on to fill in the fields as req'd.
All I'm doing is looking for the code to see what commands were sent to
get what info.
Since it's a Telnet app, it's just sending commands and parsing return
string data.
That's why I don't understand why this took months and months in the first
place.
It's not like coding for heavy graphics or anything like that.
Thanks for listening !!!!!
DanS
DanS
news:OhCQBkJj...@TK2MSFTNGP06.phx.gbl:
> And this guy was paid for his efforts?
Yes. (Although I don't know how much, but hourly, not a one price deal.)
I guess it can all be explained by saying the original coder is a 2nd
year college student that my boss knows from the highschool robot club
that his daughter was in.
The boss hired him to do this because he supposedly had programming
experience, and I was super busy at that time.
Two months ago when I and another guy in my company reviewed what was
done so far, we both expressed how bad we thought the UI design was (and
bugs in the functionality, but it was early), but no one listened. The
boss chose to stay the course.
Last week, he told me this project was "mine", to tweak as necessary.
Unfortunately 'tweak', in this instance, means 'scrap and do over'.
(I've got some really heavy deja vu feeling right now.)
I'll have to make a video of the app when I'm done, the original I was
handed vs. the remake.
OK....back to it.....
Thanks for taking the time to read my rant.
DanS
David Kaye
>.........but he also left control names at their default.........
>
Actually I have no problem with that. It sounds like he learned from the
examples in programming books, since lots of those books and Microsoft's own
examples usually don't rename controls, either.
>.........option controls named Option4, Option5, etc..........
>
For me I usually put togther arrays of option and checkbox controls and then
load them all at once and save them through one routine. Sure cuts down the
code.
>.........and then there's individual Frames, and Frames that are control
>arrays, and individual labels, and labels that are control arrays.
I usually do labels as arrays since labels normally don't have code associated
with them and it's easier to cut and past new labels as needed.
David Kaye
question of style, and unfortunately people have different styles.
For instance, I label my database objects, db, and my recordsets as ds (for
dataset), not the more conventional rs. I do this because it's easier in my
mind to associate ds with db. Other coders hate this.
I also insist on labeling variables rather than declaring them as types. This
is because I immediately know without looking at the top of the page that i%
is an integer and a$ is a string. Of course, I'll declare types when needed.
(My default date variable name is called dayte and I define it as dayte as
date.)
My conventions are, of course, integer counters are i%, j%, k% in that order.
Raw strings read from files or other input are a$, b$, c$. Counts that are
incremented I label ct% (oh, and if there is any remote possibility that
something will ever exceed integer limits I declare them as longs, such as i&,
j&, k&, ct&, etc. I should normally do them all as longs but...
What else...
Oh, unless I am managing multiple text files that could be read simultaneously
(which is highly unlikely), I tend to skip freefile entirely and simply write
the code as: open "filename" for input as #1
I don't change default control names unless really necessary. It's just
easier for me to spot a button or a checkbox or listbox and know that the
routine correctly relates to it than to read things like chkReadOnly.
Oh, and I never use data controls or "friend" controls. To me that's just
lame.
Okay, have at me.... :)
C. Kevin Provance
| examples in programming books, since lots of those books and Microsoft's
own
| examples usually don't rename controls, either.
I find that hard to believe. My first book was VB3 for Dummies and even
*that* book used proper naming conventions for controls.
DanS
news:hhreo5$7uo$3...@news.eternal-september.org:
> Now, as to good and bad programming practices, I think that some of
> this is a question of style, and unfortunately people have different
> styles.
>
> For instance, I label my database objects, db, and my recordsets as ds
<SNIP>
> (which is highly unlikely), I tend to skip freefile
> entirely and simply write the code as: open "filename" for input as
> #1
>
> I don't change default control names unless really necessary. It's
> just easier for me to spot a button or a checkbox or listbox and know
> that the routine correctly relates to it than to read things like
> chkReadOnly.
>
> Oh, and I never use data controls or "friend" controls. To me that's
> just lame.
>
> Okay, have at me.... :)
To each his own, although this project was initially spec'd to be handed
over for maintenance after the initial design. Because of that, I'd take a
little more time myself (and I am) to rename controls and use variable
names that are hopefully more self-documenting, in addition to adding REMs
that describe what's going on functionally. (REMs don;t need to be highly
detailed, just at least enough to know generally what's going on in a
function or sub, in addition to the self-documenting control names and
variables.
Larry Serflaten
"David Kaye" <sfdavi...@yahoo.com> wrote
> Now, as to good and bad programming practices, I think that some of this is a
> question of style, and unfortunately people have different styles.
I consider style having more to do with the choice of algorithm, rather than
the naming convention.
> I also insist on labeling variables rather than declaring them as types. This
> is because I immediately know without looking at the top of the page that i%
> is an integer and a$ is a string.
Using an appropreate name would achieve similar results. For example
Name is most likely and string while Value is numeric. However, I typically
use few variables anyway, and common use variables (incrementors, counters)
are usually only three letters; idx, cnt, inc, tot, pos, itm, etc...
If you use so many variables that you can't remember what is what, I'd say
you're using too many!
> Of course, I'll declare types when needed.
There are exceptions...
> My conventions are, of course, integer counters are i%, j%, k% in that order.
> Raw strings read from files or other input are a$, b$, c$. Counts that are
> incremented I label ct% (oh, and if there is any remote possibility that
> something will ever exceed integer limits I declare them as longs, such as i&,
> j&, k&, ct&, etc. I should normally do them all as longs but...
All variables should be Longs unless there is a need otherwise...
> I don't change default control names unless really necessary.
I prefer control arrays, Labels, Buttons, Texts, Frames, unless its just
a one-off app or control.
> Okay, have at me.... :)
You forgot about Parameter names, and Module level vs. Procedure level
identification. Along with using fewer variables, the procedure variables are
usually all lower case, with module level variables fully named using proper
case (for each word). Shadowed properties typicaly use the mXXX
convention (Name property and its module level shadow mName).
To each their own, unless otherwise ordered!
LFS
Ralph
"Larry Serflaten" <serf...@usinternet.com> wrote in message
news:ubRltgOj...@TK2MSFTNGP02.phx.gbl...
>
>
> You forgot about Parameter names, and Module level vs. Procedure level
> identification. Along with using fewer variables, the procedure variables
are
> usually all lower case, with module level variables fully named using
proper
> case (for each word). Shadowed properties typicaly use the mXXX
> convention (Name property and its module level shadow mName).
>
One suggestion. Avoid "mID" as a member variable name.
-ralph
C. Kevin Provance
news:ezstyzOj...@TK2MSFTNGP04.phx.gbl...
|
| One suggestion. Avoid "mID" as a member variable name.
|
| -ralph
|
|
Or sTop
David Kaye
>I find that hard to believe. My first book was VB3 for Dummies and even
>*that* book used proper naming conventions for controls.
All you have to do is look at Microsoft's own help file for any function,
command, or control to see that what I say is true.
David Kaye
>To each his own, although this project was initially spec'd to be handed
>over for maintenance after the initial design. Because of that, I'd take a
>little more time myself (and I am) to rename controls and use variable
>names that are hopefully more self-documenting, in addition to adding REMs
>that describe what's going on functionally.
I was actually pointing out the rawest of variables such as counters,
iterators, and strings gleaned from files.
For variables representing specific information, such as in a weather program
where I have that parses weather data files, indeed, I have variables such as
sky$, wx$, vis! (for visibility in miles or km), wxicon% (for an icon number
representing the weather), etc.
I also put in lots of rems, especially if I'm doing something out of the
ordinary. Most certainly if I go back the next day and have any doubts about
what the code does, I rem it, too.
Here's a random example of something I typically do. In this case, db is a
globally defined database connection. See whether it's readable or not:
Sub AddLog(ErrCode&, ErrorDesc$, Module$)
Rem date is automatically added in db
Dim ds2 As Recordset
Set ds2 = db.OpenRecordset("select * from logs where id = -555")
ds2.AddNew
ds2("error") = ErrCode&
ds2("description") = Left$(ErrorDesc$, ds2("description").Size)
ds2("module") = Module$
ds2.Update
ds2.Close
List5.AddItem Format(Now, "m/d h:mmam/pm") & vbTab & ErrCode& & vbTab &
Module$ & vbTab & ErrorDesc$
List5.TopIndex = List5.ListCount - 1
db.Execute "delete from logs where dayte < #" & Now - 60 & "#"
Rem removing logs more than 60 days old dak 5-7-09
End Sub
Mike Williams
"David Kaye" <sfdavi...@yahoo.com> wrote in message
news:hhsahd$nor$3...@news.eternal-september.org...
> All you have to do is look at Microsoft's own help file for any
> function, command, or control to see that what I say is true.
Although I would agree that Micro$oft are and always have been absolute
rubbish at writing help files, I would nevertheless agree with their use of
default names for the various Controls in their usually fairly small code
examples in the VB6 and other help. At least the default name makes it
abundantly clear throughout the example which Control(s) they are actually
using, something which would not necessarily be the case if they used more
descriptive names. Such descriptive names are fine and in fact very much
preferred in production code, but in small help files they just get in the
way of the explanation.
Mike
David Kaye
>
>Or sTop
>
Oh sTop, you're killing me!
:)
C. Kevin Provance
news:%23BXni3R...@TK2MSFTNGP05.phx.gbl...
| Although I would agree that Micro$oft are and always have been absolute
| rubbish at writing help files, I would nevertheless agree with their use
of
| default names for the various Controls in their usually fairly small code
| examples in the VB6 and other help. At least the default name makes it
| abundantly clear throughout the example which Control(s) they are actually
| using, something which would not necessarily be the case if they used more
| descriptive names. Such descriptive names are fine and in fact very much
| preferred in production code, but in small help files they just get in the
| way of the explanation.
The MS help file in terms of examples have never been very clear, so I tend
to only used them for the explainitory value. The only time and place I've
seen for default use of control names for sample purposes would be something
like Randy Birch's site. He does this so one need do is copy and paste his
code into a default project with default controls and it will run. Of
course, sites like Randy's (and Karl's) assume one knows the basics of VB.
If I'm looking for examples or help, I use Google. There has typically been
something better out there to explain a concept than MSFT's VB help file.
The Oct 2001 MSDN doesn't hurt to have either. ;-)
mayayana
for Dummies and even
> >*that* book used proper naming conventions for controls.
>
> All you have to do is look at Microsoft's own help file for any function,
> command, or control to see that what I say is true.
>
Though one would expect that people would
have enough sense to see that "Command1" is
only a stand-in name.
But that's just MyOpinion. Others are MyFree to
have TheirOpinions about TheirControls. :)
Ralph
Not in my experience.
I've found over the years that if people would only use those conventions
which I feel are correct and proper everything goes more smoothly. Random
expressions of individual freedom and diverse opinions only add confusion
and wasted effort to any project.
-ralph
Tom Shelton
I have to agree. The time for freedom of expression is during the teams
initial formation and coding standards are put together. Once determined -
there is no more freedom. They are set and anyone that violates said
standards will pay!
--
Tom Shelton
mayayana
>
> I've found over the years that if people would only use those conventions
> which I feel are correct and proper everything goes more smoothly. Random
> expressions of individual freedom and diverse opinions only add confusion
> and wasted effort to any project.
>
Yes, but it's too much trouble to write such
long names as RalphsButton and RalphsTextBox. :)
It's interesting that people here assume their own
environment is common to all. Some of us are loners
and some of us are on corporate "teams". Those
are very different situations. I can imagine that a
"team" member whose are used to a consensus might
find my style quirky, even "wrong". But I put up
with such things as underscore mania (it drives me
crazy that I have to reach over to SHIFT for that).
So I guess team players can put up with an occasional
foray outside the comforting confines of corporate
soft fascism. :)
Tom Shelton
Even in my own code, I try to keep things consistent at least with-in a
project. I also try to refactor older code as I update it to the new
standards. This is cake in vs, as it's a built in feature to rename all
references - I'm certain there must be refactoring tools for VB6 as well.
--
Tom Shelton
DanS
news:OKbBItXj...@TK2MSFTNGP02.phx.gbl:
>> Not in my experience.
>>
>> I've found over the years that if people would only use those
>> conventions which I feel are correct and proper everything goes more
>> smoothly. Random expressions of individual freedom and diverse
>> opinions only add confusion and wasted effort to any project.
>>
>
> Yes, but it's too much trouble to write such
> long names as RalphsButton and RalphsTextBox. :)
>
> It's interesting that people here assume their own
> environment is common to all.
As Tom said, I do keep my control names the same from project to project,
and not necessarily long names, but (what I would think) common....
I'm constantly doing small utils and such with IP or RS232.
So I'd typically use...
txtIP
cmbIP
lblIP
txtUName
txtPass
txtPort
cmbPort
I don't rename completely static labels.
But, below is a list of one form in the original project I ran through a
filter to list the controls....you can see the one's with duplicate names
are control arrays.....I've got to look at the original UI, find out the
'field' name then search in the code for the name to see how the value's
getting filled in......(and then code my own interpretation of it).
Thanks for your time,
DanS
Begin VB.Form Form2
Begin VB.Timer Timer1
Begin VB.OptionButton Option13
Begin VB.Frame Frame9
Begin VB.TextBox Text11
Begin VB.Frame frm
Begin VB.Frame Frame5
Begin VB.Timer Timer2
Begin VB.TextBox txtWireless
Begin VB.Frame Frame5
Begin VB.Label Label17
Begin VB.Label Label9
Begin VB.Label Label9
Begin VB.Label Label16
Begin VB.Label Label9
Begin VB.Label Label15
Begin VB.Label Label9
Begin VB.Label Label14
Begin VB.Label Label9
Begin VB.Label Label13
Begin VB.Label Label9
Begin VB.Label Label12
Begin VB.Label Label9
Begin VB.Label Label11
Begin VB.Label Label9
Begin VB.Label Label10
Begin VB.Label Label9
Begin VB.Label Label8
Begin VB.Label Label18
Begin VB.Label Label19
Begin VB.Frame Frame5
Begin VB.Frame frm
Begin VB.Frame frm
Begin VB.TextBox Text18
Begin VB.TextBox Text17
Begin VB.TextBox Text16
Begin VB.TextBox Text15
Begin VB.TextBox Text14
Begin VB.TextBox Text13
Begin VB.TextBox Text12
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Frame frm
Begin VB.Frame Frame8
Begin VB.TextBox Text19
Begin VB.TextBox Text20
Begin VB.TextBox Text21
Begin VB.TextBox Text22
Begin VB.TextBox Text23
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.OptionButton Option10
Begin VB.OptionButton Option9
Begin VB.Label Label3
Begin VB.Frame frm
Begin VB.Frame Frame7
Begin VB.TextBox Text24
Begin VB.OptionButton Option12
Begin VB.OptionButton Option11
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Frame Frame6
Begin VB.CommandButton Command1
Begin VB.CommandButton Command2
Begin VB.CommandButton Command3
Begin VB.CommandButton Command4
Begin VB.Frame frm
Begin VB.Frame Frame9
Begin VB.TextBox Text47
Begin VB.TextBox Text46
Begin VB.TextBox Text42
Begin VB.TextBox Text41
Begin VB.TextBox Text40
Begin VB.TextBox Text39
Begin VB.TextBox Text38
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Frame Frame9
Begin VB.TextBox Text37
Begin VB.TextBox Text36
Begin VB.TextBox Text35
Begin VB.TextBox Text34
Begin VB.TextBox Text33
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Frame Frame9
Begin VB.TextBox Text32
Begin VB.TextBox Text31
Begin VB.TextBox Text30
Begin VB.TextBox Text29
Begin VB.TextBox Text28
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Frame frm
Begin VB.CommandButton Command6
Begin VB.CommandButton Command7
Begin VB.CommandButton Command5
Begin VB.FileListBox File2
Begin VB.FileListBox File1
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Frame frm
Begin VB.Frame Frame9
Begin VB.Frame Frame9
Begin VB.TextBox Text27
Begin VB.TextBox Text26
Begin VB.TextBox Text25
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.OptionButton Option14
Begin VB.OptionButton Option15
Begin VB.Line Line1
Begin VB.Label Label3
Begin VB.Frame frm
Begin VB.Frame Frame1
Begin VB.Frame Frame3
Begin VB.OptionButton Option8
Begin VB.OptionButton Option7
Begin VB.Label Label2
Begin VB.Frame Frame3
Begin VB.OptionButton Option6
Begin VB.OptionButton Option5
Begin VB.Label Label2
Begin VB.Frame Frame3
Begin VB.OptionButton Option4
Begin VB.OptionButton Option3
Begin VB.Label Label2
Begin VB.Frame Frame2
Begin VB.OptionButton Option2
Begin VB.OptionButton Option1
Begin VB.Label Label1
Begin VB.Frame Frame4
Begin VB.TextBox Text10
Begin VB.CheckBox Check1
Begin VB.TextBox Text9
Begin VB.TextBox Text8
Begin VB.TextBox Text7
Begin VB.TextBox Text6
Begin VB.TextBox Text5
Begin VB.TextBox Text4
Begin VB.TextBox Text3
Begin VB.TextBox Text2
Begin VB.TextBox Text1
Begin VB.Label Label3
Begin VB.Label Label7
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label6
Begin VB.Label Label5
Begin VB.Label Label4
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label btn
Begin VB.Label Label3
Begin VB.Label Label3
Begin VB.Label btn
Begin VB.Label btn
Begin VB.Label btn
Begin VB.Label btn
Begin VB.Label btn
Begin VB.Label btn
Ralph
That style is called "warts", which IMHO is an apt description.
Tony Toews [MVP]
>I don't rename completely static labels.
Agreed. But as soon as I want to do something with it in code it gets
a name like lblEmailSubject.
MarkJ
small teams with largish systems with development lifetimes of 15
years so far (largish might mean a set of a dozen programs each with
about 10,000 lines)
The most important rule: when modifying existing code, follow the
conventions in the existing code. The very worst nightmare is a
mishmash of different conventions in one source file or one routine.
Rule 2: any convention is better than none. Pick any convention your
team can agree on - especially the most respected programmers (bosses
have no say if they are nontechnical). Don't waste time arguing
details. And individuals should be adaptable - even if you've
developed your own rigid conventions during years of lone programming,
it's really surprisingly easy to adapt to a new convention.
Rule 3: carry out code reviews to make sure another human can
understand the code. This also keeps comments accurate
My personal preference is for longish variable names and long routine
names. Avoid abbreviations or amusing mispellings (dayte?? LOL!). Y?
bcos itz hrd 2 reed. Hungarian prefixes can be useful especially for
variable scope and lifetime (global, public, module-level, static...).
Give controls meaningful names straightaway, except labels. Control
arrays are useful. Add comments.
DanS
> Rule 3: carry out code reviews to make sure another human can
> understand the code.
This is what started my whole rant. Two different reviewers (myself and
another guy inside that I would consider similar to whom the end-user would
be) *did* review the s/w. After 1 month in, we reviewed it and told the
boss we didn't like it, it was ugly, the functionality wasn't there, and
neither of us like the direction it was going.
After the two month review, we tell him the same thing.
Now, two months later, it's handed over to me.
Regards,
DanS
Ralph
Ha.
The most frustrating fact of business life, in IT and everywhere else, is
that ALL decisions are made by the individual who has the power to make the
decision - NOT necessarily the individual most qualified to make it.
-ralph
Schmidt
"DanS" <t.h.i.s....@r.o.a.d.r.u.n.n.e.r.c.o.m> schrieb im Newsbeitrag
news:Xns9CF75AC9F4F1Bth...@216.196.97.131...
> This is what started my whole rant. Two different reviewers
> (myself and another guy inside that I would consider similar
> to whom the end-user would be) *did* review the s/w.
> After 1 month in, we reviewed it and told the boss we
> didn't like it, it was ugly, the functionality wasn't there, and
> neither of us like the direction it was going.
>
> After the two month review, we tell him the same thing.
>
> Now, two months later, it's handed over to me.
Just want to add some things to this "ranting-thread"
(some points in an "opposite view", since the "contractor"
probably will not speak up here ... ever ;-))
This "contractor-business" is not an easy one, since
not always are you paid on an "open end, hourly base" -
often there's a "cutting-point", which defines something
like a maximum-payment - not sure if there was such a
cut in your case - or if the "hourly-rate" was worth
its name <g>...
So (as a contractor) you will need to finish "in time" - and
sadly far too often that means: "no matter how" - each hour
counts, sometimes your contract-projects "just-do-not-
come-in" - sometimes your contracts come in, but in
a fashion you can barely handle "all at once" - but to
be prepared for the next "hole", you want (need) to
make damn sure, you're not missing a single one of them...
It's often too easy, to blame someone from the "secure
realm of a regular job" or "even from retirement" ;-) ...
(no pun intended) ... would dare to say, that we all have
our "skeletons in the closet"...
So, don't be too hard in your "judgement" - if the code does
what it was meant to do - and (aside from the naming of Controls
and Variables) is not "all that bad" - and there are some
comments (at least at the "most critical points") - why
not show some more "generosity"...
It's *never* "pure joy" to read through an e.g. midsized project
which came from "a different mind" (no matter, how good
or bad the "naming" was).
And from your comments, it seems you are able, to make
your way through pretty fast now (with regards to your
refactoring) - so it seems, his assumption (that "you all" are
capable enough "to understand", no matter what style was
used), was not all that wrong... ;-)
Aside from that, the VB-IDE is indeed very forgiving with
regards to Control-Naming, since you can use (misuse?) the
Form- and UserControl-Designers as something like a
"Hyperlinked-HelpSystem". You don't really need to care
about naming (as long as we talk about Event-Code), since
double-clicking a Control ensures, that you are "right
there in no time". And what sometimes can be an advantage
(with regards to VBs Default-Naming), is that you
can even deduce the "build up process of a given Form"
from the Control-Names indexes (from "easy -> to more
complex").
Don't know why I wrote this - probably in an "act of self-
defense", because my coding-style is also not the best... ;-)
...or maybe because I was struggling too from time to time
with "underpayed contract-projects"... (everybody seems
to smell somehow, if you're "badly in need" or not so).
But of course one can destroy his own reputation pretty fast,
overdoing "quick and dirty" coding-style in contract-projects -
but as said, that's sometimes something "out of a cycle", which
cannot be broken very easily (even if you know better).
Olaf
dpb
...
> Just want to add some things to this "ranting-thread"
> (some points in an "opposite view", since the "contractor"
> probably will not speak up here ... ever ;-))
...
> So, don't be too hard in your "judgement" - if the code does
> what it was meant to do - and (aside from the naming of Controls
> and Variables) is not "all that bad" - and there are some
> comments (at least at the "most critical points") - why
> not show some more "generosity"...
...
Other points elided for brevity...
I tend to agree to a point--the only comment really I would have here is
that it appears the "contractor" in this case was actually a young kid
if I understood one of the follow-on's correctly.
It's not particularly surprising the code in such a case looks as it
does and I'd surmise there's a good chance this "project" has changed
from a sidelight to a more significant one than was initially envisioned...
From another long-time "contractor"... :)
--
DanS
> what it was meant to do - and (aside from the naming of Controls
> and Variables) is not "all that bad" - and there are some
> comments (at least at the "most critical points") - why
> not show some more "generosity"...
I've been on the sub-contractor side too, so I knwo these things.
But...it doesn't even do what it's supposed to do very well....if at all.
For example, there was a login form that was shown, then after a
successful login, the login form d/l's some data, decides what the base
configuration is, and then loads the specific form, and proceeds to fill
on the configuration info into the forms controls.
......however, when I got it, and running in the IDE, to see the debug
info he was printing which was the received data, it didn't work that way
(in IDE or compiled).
I could see after a connection was attempted, the initial data sent back,
and the login form sits there doing nothing. 10 seconds later I'd see the
identical info scroll by in the immediate window, and then another 10
seconds later it would scroll by again. At that point, a messagebox would
pop up saying it looked as if I dropped the connection and to try again.
As soon as that message box was dismissed, the login form was hidden and
the config form was shown, with some initial info filled in. (Which
apparently meant the connection was not lost.)
........The boss, and the coder called me on the phone two weeks ago when
he was having problems with some overflow error cause by the function
that initiates the connection, and he couldn't trace it down.
On the phone, he said something that didn't strike me at the time, but it
was that 'connect is called from several locations in code', and he
couldn't find out where the call was coming from. But, if it's a telnet
app which you log in, and send and receive data, why is it trying to
connect from multiple places ? It should only connect by the 'Login'
button. The message box told me the connection was lost and to try to
connect again. It didn't even ask me if it wanted me to try.
> It's *never* "pure joy" to read through an e.g. midsized project
> which came from "a different mind" (no matter, how good
> or bad the "naming" was).
> And from your comments, it seems you are able, to make
> your way through pretty fast now (with regards to your
> refactoring) - so it seems, his assumption (that "you all" are
> capable enough "to understand", no matter what style was
> used), was not all that wrong... ;-)
This is a telnet app, send commands, parse return data, send more
commands, parse more return data.
The only thing I really used the original code for was to see what
commands were being sent to get what data returned.
Here, here's a couple pics.....
The UI of the old project I was passed......
http://freakneck.cjb.net:8000/OldUI.jpg
The redesigned UI......
http://freakneck.cjb.net:8000/NewUI.jpg
I know the look of the explorer bar is a bit dated as well the tabstrip,
but in haste, this is the best I could do.
<SNIP>
>
> Don't know why I wrote this - probably in an "act of self-
> defense", because my coding-style is also not the best...
Maybe self-defense, but, your VB knowledge is overwhelming, which
overcomes most faults.
DanS
DanS
news:hhvolu$4t4$1...@news.eternal-september.org:
> Schmidt wrote:
> ...
>
>> Just want to add some things to this "ranting-thread"
>> (some points in an "opposite view", since the "contractor"
>> probably will not speak up here ... ever ;-))
> ...
>
>> So, don't be too hard in your "judgement" - if the code does
>> what it was meant to do - and (aside from the naming of Controls
>> and Variables) is not "all that bad" - and there are some
>> comments (at least at the "most critical points") - why
>> not show some more "generosity"...
>
> ...
>
> Other points elided for brevity...
>
> I tend to agree to a point--the only comment really I would have here
> is that it appears the "contractor" in this case was actually a young
> kid if I understood one of the follow-on's correctly.
A second year college student, an Eastern Indian long-time geek that was
the star of the bosses daughters 'robot club' when he was still in HS.
>
> It's not particularly surprising the code in such a case looks as it
> does and I'd surmise there's a good chance this "project" has changed
> from a sidelight to a more significant one than was initially
> envisioned...
Maybe.
dpb
> dpb <no...@non.net> wrote in
> news:hhvolu$4t4$1...@news.eternal-september.org:
>
>> Schmidt wrote:
>> ...
>>
>>> Just want to add some things to this "ranting-thread"
>>> (some points in an "opposite view", since the "contractor"
>>> probably will not speak up here ... ever ;-))
>> ...
>>
>>> So, don't be too hard in your "judgement" - if the code does
>>> what it was meant to do - and (aside from the naming of Controls
>>> and Variables) is not "all that bad" - and there are some
>>> comments (at least at the "most critical points") - why
>>> not show some more "generosity"...
>> ...
>>
>> Other points elided for brevity...
>>
>> I tend to agree to a point--the only comment really I would have here
>> is that it appears the "contractor" in this case was actually a young
>> kid if I understood one of the follow-on's correctly.
>
> A second year college student, an Eastern Indian long-time geek that was
> the star of the bosses daughters 'robot club' when he was still in HS.
Pretty much the definition of "kid" in my dictionary... :)
Hardly "ready for prime time" consultant. Not to say it's not pita to
have to pick up, but sounds like got about what one would expect (altho
hindsight is easy, too)... :)
--
--
Tony Toews [MVP]
>While we're swapping prejudices... here's mine: my experience is in
>small teams with largish systems with development lifetimes of 15
>years so far (largish might mean a set of a dozen programs each with
>about 10,000 lines)
My background is Access although most of my time is spent in VBA. I
work by myself usually on systems I've built for clients.
Your comments, especially about the non techie bosses, sure sound
quite reasonable to me.
Schmidt
"DanS" <t.h.i.s....@r.o.a.d.r.u.n.n.e.r.c.o.m> schrieb im Newsbeitrag
> I've been on the sub-contractor side too, so I knwo these things.
>
> But...it doesn't even do what it's supposed to do very well....if at all.
Ok, then dpb is probably right, that the developer was a
relative "young one" (also the tendency for "coloring up"
something like "a cool GUI" suggests that ;-).
From your other comments (didn't read the entire thread
fully so far) - it seems, that your task is not reduced to some
"renaming" or "mere solidifying" of the GUI - the communication-
class (encapsulating the telnet-session, internally using the
sockets and their "Events") should only exist once of course -
and these "double-connect-calls" suggest, that there's no clear
splitting between the telnet-functionality and more or less
"decoupled GUI-interaction"...
Also a better "state-reporting" from within that telnet-class
(some Properties as IsConnected, IsWaitingForResult,
CurrentTelNetMenuPage, LastRequestType... for example)
would be of help in the workflow through all the forms...
But at least it seems, that all the needed Text-Commands are
already figured out, to communicate with the WLAN-
device in question (at least that seems something, you don't
need to fiddle around with anymore).
Hope you're able to make your way through without losing
too much hair... ;-) ... good luck!
Olaf
DanS
> already figured out, to communicate with the WLAN-
> device in question (at least that seems something, you don't
> need to fiddle around with anymore).
Yeah.....about that.....
.....I too sort of jumped right into the redesign w/o thinking everything
completely through and just followed his lead and sending the same
commands and such....for instance, to get all the LAN settings, I need to
send 4 different commands, too get WAN settings, 5 different commands,
etc.
In total, there 15 command and response sequences to get all the data
filled in.
It wasn't until after I was done with retreiving the settings for the
initial config type, that I recalled this device has a command you issue
and it spits out *ALL* the config info in one stream. So I'm over here
sending command1, parsing return data, send command 2, parse more data,
etc., when all I needed to do was issue the other command to get
everything back, and then parse once.
Not only does using 15 command/responses take longer, but it makes the
code much more complex too, seeming as the parsing routine needs to know
which of the 15 commands is being sent, so I need to set flow_controlling
variables and such.
Even though the 15 commmand thing is implemented, I'm going to change it
to the single command. It's just the right thing to do.
>
> Hope you're able to make your way through without losing
> too much hair... ;-) ... good luck!
Thanks.
Regards,
DanS
David Kaye
>The most important rule: when modifying existing code, follow the
>conventions in the existing code. The very worst nightmare is a
>mishmash of different conventions in one source file or one routine.
Amen. No argument from me here.
>My personal preference is for longish variable names and long routine
>names. Avoid abbreviations or amusing mispellings (dayte?? LOL!).
I use "dayte" for a reason. I can't use "date". To me, "dayte" always refers
to the current date or the realtime date that was saved in the database.
I refer to other references to the date with other names such as: StartDate,
EndDate, DateAdded, DateSold, etc.
Tony Toews [MVP]
>Even though the 15 commmand thing is implemented, I'm going to change it
>to the single command. It's just the right thing to do.
And that separates the very good folks from the script kiddies.
deactivated
wrote:
>
>for Dummies and even
>> >*that* book used proper naming conventions for controls.
>>
>> All you have to do is look at Microsoft's own help file for any function,
>> command, or control to see that what I say is true.
>>
>
> Though one would expect that people would
>have enough sense to see that "Command1" is
>only a stand-in name.
Hmmm...stil better than what I did witness.
When i started programming in my stage in VB6, the other guy on the
stage used to name his variables m,n,g etc. and keep the default names
for controls.
Upon being told it would make debugging easier to name varaibles, he
took to renaming them to Arthur and Gaston and such and the controls
to CommandToGetOK, CANCEL and Retrieve.
I kid you not.
He was hopeless...
Bob Butler
"deactivated" wrote in message news:4b46a728...@news.newshosting.com...
> On Mon, 4 Jan 2010 10:04:04 -0500, "mayayana" <mayaX...@rcXXn.com>
> Upon being told it would make debugging easier to name varaibles, he
> took to renaming them to Arthur and Gaston and such
LOL
Karl E. Peterson
> DanS <t.h.i.s....@r.o.a.d.r.u.n.n.e.r.c.o.m> wrote:
>
>> .........but he also left control names at their default.........
>
> Actually I have no problem with that. It sounds like he learned from the
> examples in programming books, since lots of those books and Microsoft's own
> examples usually don't rename controls, either.
I think that's very valid in *printed* examples, and even in many/most
simple downloadable examples. The point of the example is to teach
some sort of functionality. The name should be *immediately*
recognizable for what it actually is, so as not to obscure the main
purpose of the example with trivia.
--
.NET: It's About Trust!
http://vfred.mvps.org
Tom Shelton
I have to agree - I don't often go through the trouble of renaming controls,
etc with sample source. I do, however, religously rename them for production
stuff - with the exception of lables - unless they are accessed in code, I
leave them at the default name.
--
Tom Shelton
Karl E. Peterson
> The MS help file in terms of examples have never been very clear, so I tend
> to only used them for the explainitory value. The only time and place I've
> seen for default use of control names for sample purposes would be something
> like Randy Birch's site. He does this so one need do is copy and paste his
> code into a default project with default controls and it will run. Of
> course, sites like Randy's (and Karl's) assume one knows the basics of VB.
I go both ways. Most often, in samples, I just leave them as default.
That makes posting just the written code extremely simple. I can say,
"On a new form with a timer and a textbox, add this code..." - would
could be clearer?
Karl E. Peterson
I'll say I "tend to" give "meaningful" names in real/live code. But it
really depends. Pretty much always for forms of "some" complexity.
For a three control popup form, not so much. <shrug>