|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
FOR ALL - Best Practices for navigating within code? -plus - Add-In's that help?number of us developers. I am somewhat new to VIsual Studio 2005 but not new to VB. I am looking for ideas about quick and efficient navigating within Visual Studio 2005. Let's say your project (or solution) has dozens of forms and hundreds or even thousands of routines. Two Questions: 1) BUILT-IN to Visual Studio 2005. What ideas do you have to quickly navigate? For example, bookmarks help. But what other ideas do you have? How do you quickly get to some routine you haven't looked at in a while and you're not totally sure what the name is? Is there some easy way to see ALL the names of ALL the routines in a project (if there is, I'm showing my ignorance here!) Here is what I know - to start out with: * Bookmarks are useful. Normally they disappear when you close your files/project - but if you leave the files open and close the SOLUTION, then bookmarks are saved. * Ctrl-minus and Ctrl-Shift-minus takes you back and forward among recently edited areas. Anyone else have further ideas? 2) Any 3rd-party add-in's that might help? Thanks, everyone! Rex Rex,
I know that the development team is consequently looking for improvements direct related to your question. The results of those are however sometimes not as we wish. It seems that everybody has different ideas about that. Than you get things as now is the help. It does for me not work anymore because the complexity and the amount of keys and steps I have to remember as well have to take to get quick the information that I need. For me they can make it more simple instead of more complex by adding keystrokes or whatever. Beside that there are pointing devices, let us forget solutions from the first days of the PC. Just my thought, Cor Show quoteHide quote "Rex" <rbas***@cfl.rr.com> schreef in bericht news:qr3bf2dipsm90m4dldn7k5qmkfoptuukh0@4ax.com... > Hi All - I have a question that I think MIGHT be of interest to a > number of us developers. I am somewhat new to VIsual Studio 2005 but > not new to VB. I am looking for ideas about quick and efficient > navigating within Visual Studio 2005. Let's say your project (or > solution) has dozens of forms and hundreds or even thousands of > routines. > > Two Questions: > > 1) BUILT-IN to Visual Studio 2005. What ideas do you have to quickly > navigate? For example, bookmarks help. But what other ideas do you > have? How do you quickly get to some routine you haven't looked at in > a while and you're not totally sure what the name is? Is there some > easy way to see ALL the names of ALL the routines in a project (if > there is, I'm showing my ignorance here!) Here is what I know - to > start out with: > * Bookmarks are useful. Normally they disappear when you close your > files/project - but if you leave the files open and close the > SOLUTION, then bookmarks are saved. > * Ctrl-minus and Ctrl-Shift-minus takes you back and forward among > recently edited areas. > Anyone else have further ideas? > > 2) Any 3rd-party add-in's that might help? > > Thanks, everyone! > > Rex > Hello Rex,
Good code organization is the most helpful. Make your classes autonomous, so you know that a function that operates on that class will be defined within that class. As an example.. I have a Polygon class.. and I recently needed to see if 2 polygons intersect or if one completely contains the other.. so I could have created a module and in the module made 2 functions (PolygonsIntersect, and PolygonContains).. this would indeed get the job done.. but it's poor design. In a 100+ file solution you'd never find those 2 functions. Instead I created the functions as Shared on the Polygon class.. so now when I need to find the function that does the check for polygon intersection.. I know it's in the Polygon.vb file. Good code organization is key. -Boo Show quoteHide quote > Hi All - I have a question that I think MIGHT be of interest to a > number of us developers. I am somewhat new to VIsual Studio 2005 but > not new to VB. I am looking for ideas about quick and efficient > navigating within Visual Studio 2005. Let's say your project (or > solution) has dozens of forms and hundreds or even thousands of > routines. > > Two Questions: > > 1) BUILT-IN to Visual Studio 2005. What ideas do you have to quickly > navigate? For example, bookmarks help. But what other ideas do you > have? How do you quickly get to some routine you haven't looked at in > a while and you're not totally sure what the name is? Is there some > easy way to see ALL the names of ALL the routines in a project (if > there is, I'm showing my ignorance here!) Here is what I know - to > start out with: > * Bookmarks are useful. Normally they disappear when you close your > files/project - but if you leave the files open and close the > SOLUTION, then bookmarks are saved. > * Ctrl-minus and Ctrl-Shift-minus takes you back and forward among > recently edited areas. > Anyone else have further ideas? > 2) Any 3rd-party add-in's that might help? > > Thanks, everyone! > > Rex > Have a look at coderush
www.devexpress.com wolfgang Show quoteHide quote "Rex" <rbas***@cfl.rr.com> schrieb im Newsbeitrag news:qr3bf2dipsm90m4dldn7k5qmkfoptuukh0@4ax.com... > Hi All - I have a question that I think MIGHT be of interest to a > number of us developers. I am somewhat new to VIsual Studio 2005 but > not new to VB. I am looking for ideas about quick and efficient > navigating within Visual Studio 2005. Let's say your project (or > solution) has dozens of forms and hundreds or even thousands of > routines. > > Two Questions: > > 1) BUILT-IN to Visual Studio 2005. What ideas do you have to quickly > navigate? For example, bookmarks help. But what other ideas do you > have? How do you quickly get to some routine you haven't looked at in > a while and you're not totally sure what the name is? Is there some > easy way to see ALL the names of ALL the routines in a project (if > there is, I'm showing my ignorance here!) Here is what I know - to > start out with: > * Bookmarks are useful. Normally they disappear when you close your > files/project - but if you leave the files open and close the > SOLUTION, then bookmarks are saved. > * Ctrl-minus and Ctrl-Shift-minus takes you back and forward among > recently edited areas. > Anyone else have further ideas? > > 2) Any 3rd-party add-in's that might help? > > Thanks, everyone! > > Rex > Thanks, Cor, Boo, and Wolfgang,
Boo, thanks for your thoughtful reply - you make an excellent point about having some excellent standard for organizing - I shall try to implement that. And Wolfgang - Thanks very much - CodeRusht looks like a fantastic product - which I think will REALLY help me in my coding. Regards, Rex On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer" <ha***@DELETETHATsysdat.at> wrote: Show quoteHide quote >Have a look at coderush >www.devexpress.com > >wolfgang >"Rex" <rbas***@cfl.rr.com> schrieb im Newsbeitrag >news:qr3bf2dipsm90m4dldn7k5qmkfoptuukh0@4ax.com... >> Hi All - I have a question that I think MIGHT be of interest to a >> number of us developers. I am somewhat new to VIsual Studio 2005 but >> not new to VB. I am looking for ideas about quick and efficient >> navigating within Visual Studio 2005. Let's say your project (or >> solution) has dozens of forms and hundreds or even thousands of >> routines. >> >> Two Questions: >> >> 1) BUILT-IN to Visual Studio 2005. What ideas do you have to quickly >> navigate? For example, bookmarks help. But what other ideas do you >> have? How do you quickly get to some routine you haven't looked at in >> a while and you're not totally sure what the name is? Is there some >> easy way to see ALL the names of ALL the routines in a project (if >> there is, I'm showing my ignorance here!) Here is what I know - to >> start out with: >> * Bookmarks are useful. Normally they disappear when you close your >> files/project - but if you leave the files open and close the >> SOLUTION, then bookmarks are saved. >> * Ctrl-minus and Ctrl-Shift-minus takes you back and forward among >> recently edited areas. >> Anyone else have further ideas? >> >> 2) Any 3rd-party add-in's that might help? >> >> Thanks, everyone! >> >> Rex >> > I guess this brings up another question.
Do you just have a comment block on commenting what the Class / functions .... etc do? For example I usually do something like this: PUBLIC CLASS ' This class blablablablbl alblablla alblalba ' balblal lbalbalb llablablaa ' and some more bla's END CALSS What do you guys put in there? Or do you even comment your classes / functions like that? -Just wondering M. Show quoteHide quote "Rex" <rbas***@cfl.rr.com> wrote in message news:1a1cf2lgv44f1fcolj4k3p73i8tcss2hl7@4ax.com... > Thanks, Cor, Boo, and Wolfgang, > Boo, thanks for your thoughtful reply - you make an excellent point > about having some excellent standard for organizing - I shall try to > implement that. > And Wolfgang - Thanks very much - CodeRusht looks like a fantastic > product - which I think will REALLY help me in my coding. > Regards, > Rex > > > On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer" > <ha***@DELETETHATsysdat.at> wrote: > >>Have a look at coderush >>www.devexpress.com >> >>wolfgang >>"Rex" <rbas***@cfl.rr.com> schrieb im Newsbeitrag >>news:qr3bf2dipsm90m4dldn7k5qmkfoptuukh0@4ax.com... >>> Hi All - I have a question that I think MIGHT be of interest to a >>> number of us developers. I am somewhat new to VIsual Studio 2005 but >>> not new to VB. I am looking for ideas about quick and efficient >>> navigating within Visual Studio 2005. Let's say your project (or >>> solution) has dozens of forms and hundreds or even thousands of >>> routines. >>> >>> Two Questions: >>> >>> 1) BUILT-IN to Visual Studio 2005. What ideas do you have to quickly >>> navigate? For example, bookmarks help. But what other ideas do you >>> have? How do you quickly get to some routine you haven't looked at in >>> a while and you're not totally sure what the name is? Is there some >>> easy way to see ALL the names of ALL the routines in a project (if >>> there is, I'm showing my ignorance here!) Here is what I know - to >>> start out with: >>> * Bookmarks are useful. Normally they disappear when you close your >>> files/project - but if you leave the files open and close the >>> SOLUTION, then bookmarks are saved. >>> * Ctrl-minus and Ctrl-Shift-minus takes you back and forward among >>> recently edited areas. >>> Anyone else have further ideas? >>> >>> 2) Any 3rd-party add-in's that might help? >>> >>> Thanks, everyone! >>> >>> Rex >>> >> Hello Miro,
Myself I'm a big fan of self-documenting code. Keep in mind there is a right way and a wrong way to do this. In order for your code to be self-documenting you have to plan.. you can't simply sit down and start typing code. To make this work you MUST have descriptive names for EVERYTHING. Something named "Cxn" or "Cnn" just aint gonna cut it. Use fully descriptive identifiers like "tConnection". Also, keep your function SMALL. As a general rule, anything over 20-30 lines of code in a single function is a bad thing. Lets say you have to set up the datatable columns, fetch some records, manipulate them, and toss them back into the database.. This is a MINIMUM of 4 different procedures (one for each action).. and off the top of my head I can thionk of several helper functions that would go with them. Yes, functionally you could roll the whole thing into a single procedure.. but it becomes hard to read and maintain then.. and this rant is about self documenting code. If you break it into 4 separate functions there's no need for comments in the code describing what blocks of code does. A function called "SetupDataTable" obviously prepares a datatable prior to filling it with data. I've got a whole philosophy for design and implementation of software.. I wont bore anyone with it unless ya ask me to. Enjoy, -Boo Show quoteHide quote > I guess this brings up another question. > > Do you just have a comment block on commenting what the Class / > functions ... etc do? > > For example I usually do something like this: > > PUBLIC CLASS > ' This class blablablablbl alblablla alblalba > ' balblal lbalbalb llablablaa > ' and some more bla's > END CALSS > > What do you guys put in there? Or do you even comment your classes / > functions like that? > > -Just wondering > M. > "Rex" <rbas***@cfl.rr.com> wrote in message > news:1a1cf2lgv44f1fcolj4k3p73i8tcss2hl7@4ax.com... > >> Thanks, Cor, Boo, and Wolfgang, >> Boo, thanks for your thoughtful reply - you make an excellent point >> about having some excellent standard for organizing - I shall try to >> implement that. >> And Wolfgang - Thanks very much - CodeRusht looks like a fantastic >> product - which I think will REALLY help me in my coding. >> Regards, >> Rex >> On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer" >> <ha***@DELETETHATsysdat.at> wrote: >> >>> Have a look at coderush >>> www.devexpress.com >>> wolfgang >>> "Rex" <rbas***@cfl.rr.com> schrieb im Newsbeitrag >>> news:qr3bf2dipsm90m4dldn7k5qmkfoptuukh0@4ax.com... >>>> Hi All - I have a question that I think MIGHT be of interest to a >>>> number of us developers. I am somewhat new to VIsual Studio 2005 >>>> but not new to VB. I am looking for ideas about quick and efficient >>>> navigating within Visual Studio 2005. Let's say your project (or >>>> solution) has dozens of forms and hundreds or even thousands of >>>> routines. >>>> >>>> Two Questions: >>>> >>>> 1) BUILT-IN to Visual Studio 2005. What ideas do you have to >>>> quickly >>>> navigate? For example, bookmarks help. But what other ideas do you >>>> have? How do you quickly get to some routine you haven't looked at >>>> in >>>> a while and you're not totally sure what the name is? Is there some >>>> easy way to see ALL the names of ALL the routines in a project (if >>>> there is, I'm showing my ignorance here!) Here is what I know - to >>>> start out with: >>>> * Bookmarks are useful. Normally they disappear when you close your >>>> files/project - but if you leave the files open and close the >>>> SOLUTION, then bookmarks are saved. >>>> * Ctrl-minus and Ctrl-Shift-minus takes you back and forward among >>>> recently edited areas. >>>> Anyone else have further ideas? >>>> 2) Any 3rd-party add-in's that might help? >>>> >>>> Thanks, everyone! >>>> >>>> Rex >>>> Thanks,
That was helpful. Im not at the stage where my Prog Is "hug" or big, but I am using descriptive Subs and Functions and so on. Just didnt want to end up with a huge prog and lost in my own code :) Miro Show quoteHide quote "GhostInAK" <ghosti***@gmail.com> wrote in message news:c71747b42e4888c89a83d12a3152@news.microsoft.com... > Hello Miro, > > Myself I'm a big fan of self-documenting code. Keep in mind there is a > right way and a wrong way to do this. In order for your code to be > self-documenting you have to plan.. you can't simply sit down and start > typing code. To make this work you MUST have descriptive names for > EVERYTHING. Something named "Cxn" or "Cnn" just aint gonna cut it. Use > fully descriptive identifiers like "tConnection". Also, keep your > function SMALL. As a general rule, anything over 20-30 lines of code in a > single function is a bad thing. Lets say you have to set up the datatable > columns, fetch some records, manipulate them, and toss them back into the > database.. This is a MINIMUM of 4 different procedures (one for each > action).. and off the top of my head I can thionk of several helper > functions that would go with them. Yes, functionally you could roll the > whole thing into a single procedure.. but it becomes hard to read and > maintain then.. and this rant is about self documenting code. If you break > it into 4 separate functions there's no need for comments in the code > describing what blocks of code does. A function called "SetupDataTable" > obviously prepares a datatable prior to filling it with data. > > I've got a whole philosophy for design and implementation of software.. I > wont bore anyone with it unless ya ask me to. > > Enjoy, > -Boo > >> I guess this brings up another question. >> >> Do you just have a comment block on commenting what the Class / >> functions ... etc do? >> >> For example I usually do something like this: >> >> PUBLIC CLASS >> ' This class blablablablbl alblablla alblalba >> ' balblal lbalbalb llablablaa >> ' and some more bla's >> END CALSS >> >> What do you guys put in there? Or do you even comment your classes / >> functions like that? >> >> -Just wondering >> M. >> "Rex" <rbas***@cfl.rr.com> wrote in message >> news:1a1cf2lgv44f1fcolj4k3p73i8tcss2hl7@4ax.com... >> >>> Thanks, Cor, Boo, and Wolfgang, >>> Boo, thanks for your thoughtful reply - you make an excellent point >>> about having some excellent standard for organizing - I shall try to >>> implement that. >>> And Wolfgang - Thanks very much - CodeRusht looks like a fantastic >>> product - which I think will REALLY help me in my coding. >>> Regards, >>> Rex >>> On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer" >>> <ha***@DELETETHATsysdat.at> wrote: >>> >>>> Have a look at coderush >>>> www.devexpress.com >>>> wolfgang >>>> "Rex" <rbas***@cfl.rr.com> schrieb im Newsbeitrag >>>> news:qr3bf2dipsm90m4dldn7k5qmkfoptuukh0@4ax.com... >>>>> Hi All - I have a question that I think MIGHT be of interest to a >>>>> number of us developers. I am somewhat new to VIsual Studio 2005 >>>>> but not new to VB. I am looking for ideas about quick and efficient >>>>> navigating within Visual Studio 2005. Let's say your project (or >>>>> solution) has dozens of forms and hundreds or even thousands of >>>>> routines. >>>>> >>>>> Two Questions: >>>>> >>>>> 1) BUILT-IN to Visual Studio 2005. What ideas do you have to >>>>> quickly >>>>> navigate? For example, bookmarks help. But what other ideas do you >>>>> have? How do you quickly get to some routine you haven't looked at >>>>> in >>>>> a while and you're not totally sure what the name is? Is there some >>>>> easy way to see ALL the names of ALL the routines in a project (if >>>>> there is, I'm showing my ignorance here!) Here is what I know - to >>>>> start out with: >>>>> * Bookmarks are useful. Normally they disappear when you close your >>>>> files/project - but if you leave the files open and close the >>>>> SOLUTION, then bookmarks are saved. >>>>> * Ctrl-minus and Ctrl-Shift-minus takes you back and forward among >>>>> recently edited areas. >>>>> Anyone else have further ideas? >>>>> 2) Any 3rd-party add-in's that might help? >>>>> >>>>> Thanks, everyone! >>>>> >>>>> Rex >>>>> > > Boo,
This what you write, is my idea as well, with the exception as a class has to give information using itelissence. However than not so much, that the rest of the screen is unussable. Cor Show quoteHide quote "GhostInAK" <ghosti***@gmail.com> schreef in bericht news:c71747b42e4888c89a83d12a3152@news.microsoft.com... > Hello Miro, > > Myself I'm a big fan of self-documenting code. Keep in mind there is a > right way and a wrong way to do this. In order for your code to be > self-documenting you have to plan.. you can't simply sit down and start > typing code. To make this work you MUST have descriptive names for > EVERYTHING. Something named "Cxn" or "Cnn" just aint gonna cut it. Use > fully descriptive identifiers like "tConnection". Also, keep your > function SMALL. As a general rule, anything over 20-30 lines of code in a > single function is a bad thing. Lets say you have to set up the datatable > columns, fetch some records, manipulate them, and toss them back into the > database.. This is a MINIMUM of 4 different procedures (one for each > action).. and off the top of my head I can thionk of several helper > functions that would go with them. Yes, functionally you could roll the > whole thing into a single procedure.. but it becomes hard to read and > maintain then.. and this rant is about self documenting code. If you break > it into 4 separate functions there's no need for comments in the code > describing what blocks of code does. A function called "SetupDataTable" > obviously prepares a datatable prior to filling it with data. > > I've got a whole philosophy for design and implementation of software.. I > wont bore anyone with it unless ya ask me to. > > Enjoy, > -Boo > >> I guess this brings up another question. >> >> Do you just have a comment block on commenting what the Class / >> functions ... etc do? >> >> For example I usually do something like this: >> >> PUBLIC CLASS >> ' This class blablablablbl alblablla alblalba >> ' balblal lbalbalb llablablaa >> ' and some more bla's >> END CALSS >> >> What do you guys put in there? Or do you even comment your classes / >> functions like that? >> >> -Just wondering >> M. >> "Rex" <rbas***@cfl.rr.com> wrote in message >> news:1a1cf2lgv44f1fcolj4k3p73i8tcss2hl7@4ax.com... >> >>> Thanks, Cor, Boo, and Wolfgang, >>> Boo, thanks for your thoughtful reply - you make an excellent point >>> about having some excellent standard for organizing - I shall try to >>> implement that. >>> And Wolfgang - Thanks very much - CodeRusht looks like a fantastic >>> product - which I think will REALLY help me in my coding. >>> Regards, >>> Rex >>> On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer" >>> <ha***@DELETETHATsysdat.at> wrote: >>> >>>> Have a look at coderush >>>> www.devexpress.com >>>> wolfgang >>>> "Rex" <rbas***@cfl.rr.com> schrieb im Newsbeitrag >>>> news:qr3bf2dipsm90m4dldn7k5qmkfoptuukh0@4ax.com... >>>>> Hi All - I have a question that I think MIGHT be of interest to a >>>>> number of us developers. I am somewhat new to VIsual Studio 2005 >>>>> but not new to VB. I am looking for ideas about quick and efficient >>>>> navigating within Visual Studio 2005. Let's say your project (or >>>>> solution) has dozens of forms and hundreds or even thousands of >>>>> routines. >>>>> >>>>> Two Questions: >>>>> >>>>> 1) BUILT-IN to Visual Studio 2005. What ideas do you have to >>>>> quickly >>>>> navigate? For example, bookmarks help. But what other ideas do you >>>>> have? How do you quickly get to some routine you haven't looked at >>>>> in >>>>> a while and you're not totally sure what the name is? Is there some >>>>> easy way to see ALL the names of ALL the routines in a project (if >>>>> there is, I'm showing my ignorance here!) Here is what I know - to >>>>> start out with: >>>>> * Bookmarks are useful. Normally they disappear when you close your >>>>> files/project - but if you leave the files open and close the >>>>> SOLUTION, then bookmarks are saved. >>>>> * Ctrl-minus and Ctrl-Shift-minus takes you back and forward among >>>>> recently edited areas. >>>>> Anyone else have further ideas? >>>>> 2) Any 3rd-party add-in's that might help? >>>>> >>>>> Thanks, everyone! >>>>> >>>>> Rex >>>>> > > Boo,
the boring part to some...is the exciting part to me... being a 'self educated' / 'self-learned' programmer ... many of my 'rules' / 'standards' have been brought about by trial and error... It is nice to read that some of the things I do, others do as well ... many times, I have hired (and fired) college and university grads simply because they do not know how to code ... your code needs to reflect your problem solving skills...if you tackle a problem as a whole and do not plan...you end up with one big sub routine with a few calls out to other modules / classes / functions which are so tightly connected to the current problem that 're' usability is out the window - you spend more time trying to solve the large problem in one fare swoop - you end up wasting time, spinning your wheels, bangin your head off the wall ... However, if you break you problem into small, managable tasks and tackle each task as a seperate, isolated project ... and break these smaller projects into task...and tackle each task as a seperate, isolated project ... for next til parent project is done ... yet get the pictue ... Now to the point... your code should reflect your approach to solving the problem... in Boos examlpe... - focus on setting up datatable columns ... prime focus ... who cares about the beginning and end ... you need to focus on setting up datatable columns .... what you do after that is another problem ... how you populate them is another problem ... Once you can setup datatable columns, move on ... - fetch some records ... prime focus ... how do i fetch some records ... need to connect to database ... need to query a table, call a stored proc, query a view ... oops... this is a bigger problem with smaller tasks ... 1. connect to database - focus / sovle ... 2. query a table for records - focus / solve ... 3. query a stored proc - focus / solve ... and so on. - maniputate the data ... on the surface ... simple ... user changes data .... done ... if there are other processes ... looking / comparing / calculating ... isolate each routine - focus / solve ... for example ... need to maniputate dates and phone numbers ... focus on date validition, date formatting, date constriants ... done ... focus on phone numbers ... validation, formatting, constraints ... done. Now, anytime you need to 'manipulate dates' ... you re-use this code ... done. - toss back to database ... prime focus ... need to connectting to datasource ... database, done already , xml file or other source ... focus, code it ... So, in the above, as Boo has already mentioned, you have at the very least 4 distinct code blocks...with four distinctly different responsibilities ... breaking code in to logical classes, functions, procedures and so on ... is a lot better than a code segment that needs 40 lines of text to explain 39 lines of code .... to me, over commenting is a bad thing... if you find yourself writing just as much comments as you do code ... you need to rethink your design approach. Now, sometimes you need to add a bunch of comments to explain something, or refresh your memory as to why you have implemented a certain approach ... this is fine ... but should be the exception and not the rule in commenting your code. Boo...I did bore...but to some, knowing others practice as you do, validates your efforts...and makes you want to talk about it. Thanks. Jeff. Show quoteHide quote "GhostInAK" <ghosti***@gmail.com> wrote in message news:c71747b42e4888c89a83d12a3152@news.microsoft.com... > Hello Miro, > > Myself I'm a big fan of self-documenting code. Keep in mind there is a > right way and a wrong way to do this. In order for your code to be > self-documenting you have to plan.. you can't simply sit down and start > typing code. To make this work you MUST have descriptive names for > EVERYTHING. Something named "Cxn" or "Cnn" just aint gonna cut it. Use > fully descriptive identifiers like "tConnection". Also, keep your > function SMALL. As a general rule, anything over 20-30 lines of code in a > single function is a bad thing. Lets say you have to set up the datatable > columns, fetch some records, manipulate them, and toss them back into the > database.. This is a MINIMUM of 4 different procedures (one for each > action).. and off the top of my head I can thionk of several helper > functions that would go with them. Yes, functionally you could roll the > whole thing into a single procedure.. but it becomes hard to read and > maintain then.. and this rant is about self documenting code. If you break > it into 4 separate functions there's no need for comments in the code > describing what blocks of code does. A function called "SetupDataTable" > obviously prepares a datatable prior to filling it with data. > > I've got a whole philosophy for design and implementation of software.. I > wont bore anyone with it unless ya ask me to. > > Enjoy, > -Boo > >> I guess this brings up another question. >> >> Do you just have a comment block on commenting what the Class / >> functions ... etc do? >> >> For example I usually do something like this: >> >> PUBLIC CLASS >> ' This class blablablablbl alblablla alblalba >> ' balblal lbalbalb llablablaa >> ' and some more bla's >> END CALSS >> >> What do you guys put in there? Or do you even comment your classes / >> functions like that? >> >> -Just wondering >> M. >> "Rex" <rbas***@cfl.rr.com> wrote in message >> news:1a1cf2lgv44f1fcolj4k3p73i8tcss2hl7@4ax.com... >> >>> Thanks, Cor, Boo, and Wolfgang, >>> Boo, thanks for your thoughtful reply - you make an excellent point >>> about having some excellent standard for organizing - I shall try to >>> implement that. >>> And Wolfgang - Thanks very much - CodeRusht looks like a fantastic >>> product - which I think will REALLY help me in my coding. >>> Regards, >>> Rex >>> On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer" >>> <ha***@DELETETHATsysdat.at> wrote: >>> >>>> Have a look at coderush >>>> www.devexpress.com >>>> wolfgang >>>> "Rex" <rbas***@cfl.rr.com> schrieb im Newsbeitrag >>>> news:qr3bf2dipsm90m4dldn7k5qmkfoptuukh0@4ax.com... >>>>> Hi All - I have a question that I think MIGHT be of interest to a >>>>> number of us developers. I am somewhat new to VIsual Studio 2005 >>>>> but not new to VB. I am looking for ideas about quick and efficient >>>>> navigating within Visual Studio 2005. Let's say your project (or >>>>> solution) has dozens of forms and hundreds or even thousands of >>>>> routines. >>>>> >>>>> Two Questions: >>>>> >>>>> 1) BUILT-IN to Visual Studio 2005. What ideas do you have to >>>>> quickly >>>>> navigate? For example, bookmarks help. But what other ideas do you >>>>> have? How do you quickly get to some routine you haven't looked at >>>>> in >>>>> a while and you're not totally sure what the name is? Is there some >>>>> easy way to see ALL the names of ALL the routines in a project (if >>>>> there is, I'm showing my ignorance here!) Here is what I know - to >>>>> start out with: >>>>> * Bookmarks are useful. Normally they disappear when you close your >>>>> files/project - but if you leave the files open and close the >>>>> SOLUTION, then bookmarks are saved. >>>>> * Ctrl-minus and Ctrl-Shift-minus takes you back and forward among >>>>> recently edited areas. >>>>> Anyone else have further ideas? >>>>> 2) Any 3rd-party add-in's that might help? >>>>> >>>>> Thanks, everyone! >>>>> >>>>> Rex >>>>> > > Jeff,
I have seen programs that did more calls (whatever that were) than actual things. I think that Best Practise has to do with the situation it is done for. Cor Show quoteHide quote "jeff" <jhersey at allnorth dottt com> schreef in bericht news:udl6ZjPzGHA.4452@TK2MSFTNGP05.phx.gbl... > Boo, > > the boring part to some...is the exciting part to me... > > being a 'self educated' / 'self-learned' programmer ... many of my 'rules' > / 'standards' have been brought about by trial and error... It is nice to > read that some of the things I do, others do as well ... many times, I > have hired (and fired) college and university grads simply because they do > not know how to code ... your code needs to reflect your problem solving > skills...if you tackle a problem as a whole and do not plan...you end up > with one big sub routine with a few calls out to other modules / classes / > functions which are so tightly connected to the current problem that 're' > usability is out the window - you spend more time trying to solve the > large problem in one fare swoop - you end up wasting time, spinning your > wheels, bangin your head off the wall ... However, if you break you > problem into small, managable tasks and tackle each task as a seperate, > isolated project ... and break these smaller projects into task...and > tackle each task as a seperate, isolated project ... for next til parent > project is done ... yet get the pictue ... > > Now to the point... > > your code should reflect your approach to solving the problem... in Boos > examlpe... > > - focus on setting up datatable columns ... prime focus ... who cares > about the beginning and end ... you need to focus on setting up datatable > columns ... what you do after that is another problem ... how you populate > them is another problem ... Once you can setup datatable columns, move on > ... > > - fetch some records ... prime focus ... how do i fetch some records ... > need to connect to database ... need to query a table, call a stored proc, > query a view ... oops... this is a bigger problem with smaller tasks ... > 1. connect to database - focus / sovle ... 2. query a table for records - > focus / solve ... 3. query a stored proc - focus / solve ... and so on. > > - maniputate the data ... on the surface ... simple ... user changes data > ... done ... if there are other processes ... looking / comparing / > calculating ... isolate each routine - focus / solve ... for example ... > need to maniputate dates and phone numbers ... focus on date validition, > date formatting, date constriants ... done ... focus on phone numbers ... > validation, formatting, constraints ... done. Now, anytime you need to > 'manipulate dates' ... you re-use this code ... done. > > - toss back to database ... prime focus ... need to connectting to > datasource ... database, done already , xml file or other source ... > focus, code it ... > > So, in the above, as Boo has already mentioned, you have at the very least > 4 distinct code blocks...with four distinctly different responsibilities > ... breaking code in to logical classes, functions, procedures and so on > ... is a lot better than a code segment that needs 40 lines of text to > explain 39 lines of code .... to me, over commenting is a bad thing... if > you find yourself writing just as much comments as you do code ... you > need to rethink your design approach. Now, sometimes you need to add a > bunch of comments to explain something, or refresh your memory as to why > you have implemented a certain approach ... this is fine ... but should be > the exception and not the rule in commenting your code. > > Boo...I did bore...but to some, knowing others practice as you do, > validates your efforts...and makes you want to talk about it. > > Thanks. > Jeff. > > "GhostInAK" <ghosti***@gmail.com> wrote in message > news:c71747b42e4888c89a83d12a3152@news.microsoft.com... >> Hello Miro, >> >> Myself I'm a big fan of self-documenting code. Keep in mind there is a >> right way and a wrong way to do this. In order for your code to be >> self-documenting you have to plan.. you can't simply sit down and start >> typing code. To make this work you MUST have descriptive names for >> EVERYTHING. Something named "Cxn" or "Cnn" just aint gonna cut it. Use >> fully descriptive identifiers like "tConnection". Also, keep your >> function SMALL. As a general rule, anything over 20-30 lines of code in >> a single function is a bad thing. Lets say you have to set up the >> datatable columns, fetch some records, manipulate them, and toss them >> back into the database.. This is a MINIMUM of 4 different procedures >> (one for each action).. and off the top of my head I can thionk of >> several helper functions that would go with them. Yes, functionally you >> could roll the whole thing into a single procedure.. but it becomes hard >> to read and maintain then.. and this rant is about self documenting code. >> If you break it into 4 separate functions there's no need for comments in >> the code describing what blocks of code does. A function called >> "SetupDataTable" obviously prepares a datatable prior to filling it with >> data. >> >> I've got a whole philosophy for design and implementation of software.. I >> wont bore anyone with it unless ya ask me to. >> >> Enjoy, >> -Boo >> >>> I guess this brings up another question. >>> >>> Do you just have a comment block on commenting what the Class / >>> functions ... etc do? >>> >>> For example I usually do something like this: >>> >>> PUBLIC CLASS >>> ' This class blablablablbl alblablla alblalba >>> ' balblal lbalbalb llablablaa >>> ' and some more bla's >>> END CALSS >>> >>> What do you guys put in there? Or do you even comment your classes / >>> functions like that? >>> >>> -Just wondering >>> M. >>> "Rex" <rbas***@cfl.rr.com> wrote in message >>> news:1a1cf2lgv44f1fcolj4k3p73i8tcss2hl7@4ax.com... >>> >>>> Thanks, Cor, Boo, and Wolfgang, >>>> Boo, thanks for your thoughtful reply - you make an excellent point >>>> about having some excellent standard for organizing - I shall try to >>>> implement that. >>>> And Wolfgang - Thanks very much - CodeRusht looks like a fantastic >>>> product - which I think will REALLY help me in my coding. >>>> Regards, >>>> Rex >>>> On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer" >>>> <ha***@DELETETHATsysdat.at> wrote: >>>> >>>>> Have a look at coderush >>>>> www.devexpress.com >>>>> wolfgang >>>>> "Rex" <rbas***@cfl.rr.com> schrieb im Newsbeitrag >>>>> news:qr3bf2dipsm90m4dldn7k5qmkfoptuukh0@4ax.com... >>>>>> Hi All - I have a question that I think MIGHT be of interest to a >>>>>> number of us developers. I am somewhat new to VIsual Studio 2005 >>>>>> but not new to VB. I am looking for ideas about quick and efficient >>>>>> navigating within Visual Studio 2005. Let's say your project (or >>>>>> solution) has dozens of forms and hundreds or even thousands of >>>>>> routines. >>>>>> >>>>>> Two Questions: >>>>>> >>>>>> 1) BUILT-IN to Visual Studio 2005. What ideas do you have to >>>>>> quickly >>>>>> navigate? For example, bookmarks help. But what other ideas do you >>>>>> have? How do you quickly get to some routine you haven't looked at >>>>>> in >>>>>> a while and you're not totally sure what the name is? Is there some >>>>>> easy way to see ALL the names of ALL the routines in a project (if >>>>>> there is, I'm showing my ignorance here!) Here is what I know - to >>>>>> start out with: >>>>>> * Bookmarks are useful. Normally they disappear when you close your >>>>>> files/project - but if you leave the files open and close the >>>>>> SOLUTION, then bookmarks are saved. >>>>>> * Ctrl-minus and Ctrl-Shift-minus takes you back and forward among >>>>>> recently edited areas. >>>>>> Anyone else have further ideas? >>>>>> 2) Any 3rd-party add-in's that might help? >>>>>> >>>>>> Thanks, everyone! >>>>>> >>>>>> Rex >>>>>> >> >> > > Cor,
Agree...calling out ... is over used in a lot of cases ... ie... MyMath Class MyMath.AddNumbers(aNumber1,aNumber2) as Doublle ReTURN aNumber1 + aNumber2) End ... Agree, if can be overused ... I have seen it too... Agree Best Practice is the situation it is done for ... but I have yet to find a situation where a single code segment is best practice for a solution to a project . my point was to identify starting points to decide where and when to call out to other functions / classes and so on ... when you have another problem to solve you have a case for another 'function' 'class' 'object' whatever .... this does not mean a decision you need to make ... ie... If a = b then ..... Else .... End if should not be replaced with if MyCompare(a,b) then .... else .... End if Unless there is more business logic in the comparison ....because if there is more business logic, this becomes a problem to solve rather than a desicion... JEff Show quoteHide quote "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message news:OPyuRKQzGHA.4968@TK2MSFTNGP05.phx.gbl... > Jeff, > > I have seen programs that did more calls (whatever that were) than actual > things. > > I think that Best Practise has to do with the situation it is done for. > > Cor > > "jeff" <jhersey at allnorth dottt com> schreef in bericht > news:udl6ZjPzGHA.4452@TK2MSFTNGP05.phx.gbl... >> Boo, >> >> the boring part to some...is the exciting part to me... >> >> being a 'self educated' / 'self-learned' programmer ... many of my >> 'rules' / 'standards' have been brought about by trial and error... It is >> nice to read that some of the things I do, others do as well ... many >> times, I have hired (and fired) college and university grads simply >> because they do not know how to code ... your code needs to reflect your >> problem solving skills...if you tackle a problem as a whole and do not >> plan...you end up with one big sub routine with a few calls out to other >> modules / classes / functions which are so tightly connected to the >> current problem that 're' usability is out the window - you spend more >> time trying to solve the large problem in one fare swoop - you end up >> wasting time, spinning your wheels, bangin your head off the wall ... >> However, if you break you problem into small, managable tasks and tackle >> each task as a seperate, isolated project ... and break these smaller >> projects into task...and tackle each task as a seperate, isolated project >> ... for next til parent project is done ... yet get the pictue ... >> >> Now to the point... >> >> your code should reflect your approach to solving the problem... in Boos >> examlpe... >> >> - focus on setting up datatable columns ... prime focus ... who cares >> about the beginning and end ... you need to focus on setting up datatable >> columns ... what you do after that is another problem ... how you >> populate them is another problem ... Once you can setup datatable >> columns, move on ... >> >> - fetch some records ... prime focus ... how do i fetch some records ... >> need to connect to database ... need to query a table, call a stored >> proc, query a view ... oops... this is a bigger problem with smaller >> tasks ... 1. connect to database - focus / sovle ... 2. query a table for >> records - focus / solve ... 3. query a stored proc - focus / solve ... >> and so on. >> >> - maniputate the data ... on the surface ... simple ... user changes data >> ... done ... if there are other processes ... looking / comparing / >> calculating ... isolate each routine - focus / solve ... for example ... >> need to maniputate dates and phone numbers ... focus on date validition, >> date formatting, date constriants ... done ... focus on phone numbers ... >> validation, formatting, constraints ... done. Now, anytime you need to >> 'manipulate dates' ... you re-use this code ... done. >> >> - toss back to database ... prime focus ... need to connectting to >> datasource ... database, done already , xml file or other source ... >> focus, code it ... >> >> So, in the above, as Boo has already mentioned, you have at the very >> least 4 distinct code blocks...with four distinctly different >> responsibilities ... breaking code in to logical classes, functions, >> procedures and so on ... is a lot better than a code segment that needs >> 40 lines of text to explain 39 lines of code .... to me, over commenting >> is a bad thing... if you find yourself writing just as much comments as >> you do code ... you need to rethink your design approach. Now, sometimes >> you need to add a bunch of comments to explain something, or refresh your >> memory as to why you have implemented a certain approach ... this is fine >> ... but should be the exception and not the rule in commenting your code. >> >> Boo...I did bore...but to some, knowing others practice as you do, >> validates your efforts...and makes you want to talk about it. >> >> Thanks. >> Jeff. >> >> "GhostInAK" <ghosti***@gmail.com> wrote in message >> news:c71747b42e4888c89a83d12a3152@news.microsoft.com... >>> Hello Miro, >>> >>> Myself I'm a big fan of self-documenting code. Keep in mind there is a >>> right way and a wrong way to do this. In order for your code to be >>> self-documenting you have to plan.. you can't simply sit down and start >>> typing code. To make this work you MUST have descriptive names for >>> EVERYTHING. Something named "Cxn" or "Cnn" just aint gonna cut it. Use >>> fully descriptive identifiers like "tConnection". Also, keep your >>> function SMALL. As a general rule, anything over 20-30 lines of code in >>> a single function is a bad thing. Lets say you have to set up the >>> datatable columns, fetch some records, manipulate them, and toss them >>> back into the database.. This is a MINIMUM of 4 different procedures >>> (one for each action).. and off the top of my head I can thionk of >>> several helper functions that would go with them. Yes, functionally you >>> could roll the whole thing into a single procedure.. but it becomes hard >>> to read and maintain then.. and this rant is about self documenting >>> code. If you break it into 4 separate functions there's no need for >>> comments in the code describing what blocks of code does. A function >>> called "SetupDataTable" obviously prepares a datatable prior to filling >>> it with data. >>> >>> I've got a whole philosophy for design and implementation of software.. >>> I wont bore anyone with it unless ya ask me to. >>> >>> Enjoy, >>> -Boo >>> >>>> I guess this brings up another question. >>>> >>>> Do you just have a comment block on commenting what the Class / >>>> functions ... etc do? >>>> >>>> For example I usually do something like this: >>>> >>>> PUBLIC CLASS >>>> ' This class blablablablbl alblablla alblalba >>>> ' balblal lbalbalb llablablaa >>>> ' and some more bla's >>>> END CALSS >>>> >>>> What do you guys put in there? Or do you even comment your classes / >>>> functions like that? >>>> >>>> -Just wondering >>>> M. >>>> "Rex" <rbas***@cfl.rr.com> wrote in message >>>> news:1a1cf2lgv44f1fcolj4k3p73i8tcss2hl7@4ax.com... >>>> >>>>> Thanks, Cor, Boo, and Wolfgang, >>>>> Boo, thanks for your thoughtful reply - you make an excellent point >>>>> about having some excellent standard for organizing - I shall try to >>>>> implement that. >>>>> And Wolfgang - Thanks very much - CodeRusht looks like a fantastic >>>>> product - which I think will REALLY help me in my coding. >>>>> Regards, >>>>> Rex >>>>> On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer" >>>>> <ha***@DELETETHATsysdat.at> wrote: >>>>> >>>>>> Have a look at coderush >>>>>> www.devexpress.com >>>>>> wolfgang >>>>>> "Rex" <rbas***@cfl.rr.com> schrieb im Newsbeitrag >>>>>> news:qr3bf2dipsm90m4dldn7k5qmkfoptuukh0@4ax.com... >>>>>>> Hi All - I have a question that I think MIGHT be of interest to a >>>>>>> number of us developers. I am somewhat new to VIsual Studio 2005 >>>>>>> but not new to VB. I am looking for ideas about quick and efficient >>>>>>> navigating within Visual Studio 2005. Let's say your project (or >>>>>>> solution) has dozens of forms and hundreds or even thousands of >>>>>>> routines. >>>>>>> >>>>>>> Two Questions: >>>>>>> >>>>>>> 1) BUILT-IN to Visual Studio 2005. What ideas do you have to >>>>>>> quickly >>>>>>> navigate? For example, bookmarks help. But what other ideas do you >>>>>>> have? How do you quickly get to some routine you haven't looked at >>>>>>> in >>>>>>> a while and you're not totally sure what the name is? Is there some >>>>>>> easy way to see ALL the names of ALL the routines in a project (if >>>>>>> there is, I'm showing my ignorance here!) Here is what I know - to >>>>>>> start out with: >>>>>>> * Bookmarks are useful. Normally they disappear when you close your >>>>>>> files/project - but if you leave the files open and close the >>>>>>> SOLUTION, then bookmarks are saved. >>>>>>> * Ctrl-minus and Ctrl-Shift-minus takes you back and forward among >>>>>>> recently edited areas. >>>>>>> Anyone else have further ideas? >>>>>>> 2) Any 3rd-party add-in's that might help? >>>>>>> >>>>>>> Thanks, everyone! >>>>>>> >>>>>>> Rex >>>>>>> >>> >>> >> >> > > I do find I am running into a bit of a grouping issue, as to :
when I write a bunch of custom generic functions where to store them. For example I like to do a lot of things in arrays. So I have a function that returns an array position of a value, another that removes a certain element and redims the array and so on. Currently I added / created a MiscLibrary Module and am most likly will have to split those up and group them accordingly as I create more and more. -That way Im assuming if later I try to create another program and these functions can be re-used I am in effect creating my own Library of Functions and Subs. -So I can just add this Module to a different Project later. I just started in VB.net so I really havnt run into your headaches yet of huge programs, but i have run into them with other languages and software created. So I am kinda following the same rules there and slowely re-writing them for vb. Thats why I guess I sometimes am looking to do something really "weird" in VB that seems "funny" to some of you when I ask some questions here. Just trying to code the same way in 1 langauge as in the other, and then slowly VB'ise it. ( If VB'ise is a real word ) Books can only take you so far. I think its the experience of another programer that does make ur life a lot simpler. So thanks for all the help so far. And if anyone needs help with any old 4Gl languages... like ProIV... Ask away :-) - But thats a different newsgroup. M. Show quoteHide quote "jeff" <jhersey at allnorth dottt com> wrote in message news:exy%23laQzGHA.4396@TK2MSFTNGP04.phx.gbl... > Cor, > > Agree...calling out ... is over used in a lot of cases ... > > ie... > > MyMath Class > > MyMath.AddNumbers(aNumber1,aNumber2) as Doublle > ReTURN aNumber1 + aNumber2) > End ... > > Agree, if can be overused ... I have seen it too... > > > Agree Best Practice is the situation it is done for ... but I have yet to > find a situation where a single code segment is best practice for a > solution to a project . > > my point was to identify starting points to decide where and when to call > out to other functions / classes and so on ... when you have another > problem to solve you have a case for another 'function' 'class' 'object' > whatever ... this does not mean a decision you need to make ... > > ie... > > If a = b then > .... > Else > ... > End if > > should not be replaced with > > if MyCompare(a,b) then > ... > else > ... > End if > > Unless there is more business logic in the comparison ....because if there > is more business logic, this becomes a problem to solve rather than a > desicion... > > JEff > > > > "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message > news:OPyuRKQzGHA.4968@TK2MSFTNGP05.phx.gbl... >> Jeff, >> >> I have seen programs that did more calls (whatever that were) than actual >> things. >> >> I think that Best Practise has to do with the situation it is done for. >> >> Cor >> >> "jeff" <jhersey at allnorth dottt com> schreef in bericht >> news:udl6ZjPzGHA.4452@TK2MSFTNGP05.phx.gbl... >>> Boo, >>> >>> the boring part to some...is the exciting part to me... >>> >>> being a 'self educated' / 'self-learned' programmer ... many of my >>> 'rules' / 'standards' have been brought about by trial and error... It >>> is nice to read that some of the things I do, others do as well ... many >>> times, I have hired (and fired) college and university grads simply >>> because they do not know how to code ... your code needs to reflect your >>> problem solving skills...if you tackle a problem as a whole and do not >>> plan...you end up with one big sub routine with a few calls out to other >>> modules / classes / functions which are so tightly connected to the >>> current problem that 're' usability is out the window - you spend more >>> time trying to solve the large problem in one fare swoop - you end up >>> wasting time, spinning your wheels, bangin your head off the wall ... >>> However, if you break you problem into small, managable tasks and tackle >>> each task as a seperate, isolated project ... and break these smaller >>> projects into task...and tackle each task as a seperate, isolated >>> project ... for next til parent project is done ... yet get the pictue >>> ... >>> >>> Now to the point... >>> >>> your code should reflect your approach to solving the problem... in Boos >>> examlpe... >>> >>> - focus on setting up datatable columns ... prime focus ... who cares >>> about the beginning and end ... you need to focus on setting up >>> datatable columns ... what you do after that is another problem ... how >>> you populate them is another problem ... Once you can setup datatable >>> columns, move on ... >>> >>> - fetch some records ... prime focus ... how do i fetch some records ... >>> need to connect to database ... need to query a table, call a stored >>> proc, query a view ... oops... this is a bigger problem with smaller >>> tasks ... 1. connect to database - focus / sovle ... 2. query a table >>> for records - focus / solve ... 3. query a stored proc - focus / solve >>> ... and so on. >>> >>> - maniputate the data ... on the surface ... simple ... user changes >>> data ... done ... if there are other processes ... looking / comparing / >>> calculating ... isolate each routine - focus / solve ... for example ... >>> need to maniputate dates and phone numbers ... focus on date validition, >>> date formatting, date constriants ... done ... focus on phone numbers >>> ... validation, formatting, constraints ... done. Now, anytime you need >>> to 'manipulate dates' ... you re-use this code ... done. >>> >>> - toss back to database ... prime focus ... need to connectting to >>> datasource ... database, done already , xml file or other source ... >>> focus, code it ... >>> >>> So, in the above, as Boo has already mentioned, you have at the very >>> least 4 distinct code blocks...with four distinctly different >>> responsibilities ... breaking code in to logical classes, functions, >>> procedures and so on ... is a lot better than a code segment that needs >>> 40 lines of text to explain 39 lines of code .... to me, over commenting >>> is a bad thing... if you find yourself writing just as much comments as >>> you do code ... you need to rethink your design approach. Now, >>> sometimes you need to add a bunch of comments to explain something, or >>> refresh your memory as to why you have implemented a certain approach >>> ... this is fine ... but should be the exception and not the rule in >>> commenting your code. >>> >>> Boo...I did bore...but to some, knowing others practice as you do, >>> validates your efforts...and makes you want to talk about it. >>> >>> Thanks. >>> Jeff. >>> >>> "GhostInAK" <ghosti***@gmail.com> wrote in message >>> news:c71747b42e4888c89a83d12a3152@news.microsoft.com... >>>> Hello Miro, >>>> >>>> Myself I'm a big fan of self-documenting code. Keep in mind there is a >>>> right way and a wrong way to do this. In order for your code to be >>>> self-documenting you have to plan.. you can't simply sit down and start >>>> typing code. To make this work you MUST have descriptive names for >>>> EVERYTHING. Something named "Cxn" or "Cnn" just aint gonna cut it. >>>> Use fully descriptive identifiers like "tConnection". Also, keep your >>>> function SMALL. As a general rule, anything over 20-30 lines of code >>>> in a single function is a bad thing. Lets say you have to set up the >>>> datatable columns, fetch some records, manipulate them, and toss them >>>> back into the database.. This is a MINIMUM of 4 different procedures >>>> (one for each action).. and off the top of my head I can thionk of >>>> several helper functions that would go with them. Yes, functionally >>>> you could roll the whole thing into a single procedure.. but it becomes >>>> hard to read and maintain then.. and this rant is about self >>>> documenting code. If you break it into 4 separate functions there's no >>>> need for comments in the code describing what blocks of code does. A >>>> function called "SetupDataTable" obviously prepares a datatable prior >>>> to filling it with data. >>>> >>>> I've got a whole philosophy for design and implementation of software.. >>>> I wont bore anyone with it unless ya ask me to. >>>> >>>> Enjoy, >>>> -Boo >>>> >>>>> I guess this brings up another question. >>>>> >>>>> Do you just have a comment block on commenting what the Class / >>>>> functions ... etc do? >>>>> >>>>> For example I usually do something like this: >>>>> >>>>> PUBLIC CLASS >>>>> ' This class blablablablbl alblablla alblalba >>>>> ' balblal lbalbalb llablablaa >>>>> ' and some more bla's >>>>> END CALSS >>>>> >>>>> What do you guys put in there? Or do you even comment your classes / >>>>> functions like that? >>>>> >>>>> -Just wondering >>>>> M. >>>>> "Rex" <rbas***@cfl.rr.com> wrote in message >>>>> news:1a1cf2lgv44f1fcolj4k3p73i8tcss2hl7@4ax.com... >>>>> >>>>>> Thanks, Cor, Boo, and Wolfgang, >>>>>> Boo, thanks for your thoughtful reply - you make an excellent point >>>>>> about having some excellent standard for organizing - I shall try to >>>>>> implement that. >>>>>> And Wolfgang - Thanks very much - CodeRusht looks like a fantastic >>>>>> product - which I think will REALLY help me in my coding. >>>>>> Regards, >>>>>> Rex >>>>>> On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer" >>>>>> <ha***@DELETETHATsysdat.at> wrote: >>>>>> >>>>>>> Have a look at coderush >>>>>>> www.devexpress.com >>>>>>> wolfgang >>>>>>> "Rex" <rbas***@cfl.rr.com> schrieb im Newsbeitrag >>>>>>> news:qr3bf2dipsm90m4dldn7k5qmkfoptuukh0@4ax.com... >>>>>>>> Hi All - I have a question that I think MIGHT be of interest to a >>>>>>>> number of us developers. I am somewhat new to VIsual Studio 2005 >>>>>>>> but not new to VB. I am looking for ideas about quick and efficient >>>>>>>> navigating within Visual Studio 2005. Let's say your project (or >>>>>>>> solution) has dozens of forms and hundreds or even thousands of >>>>>>>> routines. >>>>>>>> >>>>>>>> Two Questions: >>>>>>>> >>>>>>>> 1) BUILT-IN to Visual Studio 2005. What ideas do you have to >>>>>>>> quickly >>>>>>>> navigate? For example, bookmarks help. But what other ideas do you >>>>>>>> have? How do you quickly get to some routine you haven't looked at >>>>>>>> in >>>>>>>> a while and you're not totally sure what the name is? Is there some >>>>>>>> easy way to see ALL the names of ALL the routines in a project (if >>>>>>>> there is, I'm showing my ignorance here!) Here is what I know - to >>>>>>>> start out with: >>>>>>>> * Bookmarks are useful. Normally they disappear when you close your >>>>>>>> files/project - but if you leave the files open and close the >>>>>>>> SOLUTION, then bookmarks are saved. >>>>>>>> * Ctrl-minus and Ctrl-Shift-minus takes you back and forward among >>>>>>>> recently edited areas. >>>>>>>> Anyone else have further ideas? >>>>>>>> 2) Any 3rd-party add-in's that might help? >>>>>>>> >>>>>>>> Thanks, everyone! >>>>>>>> >>>>>>>> Rex >>>>>>>> >>>> >>>> >>> >>> >> >> > > Hello Miro,
Just a quick thought.. Nothin wrong with arrays.. but I prefer Collections (collections, lists, hashtables, arraylists, stacks, queues, etc) as they fit in with the object-oriented approach a lil better than standard arrays. They also have built-in support for adding/removing/indexing and they eliminate the need to ReDim anything. Explore both and see what you think. Also with the addition of generics in 2.0 (Or CodeSmith for 1.1 (CodeSmith is awesome for 2.0 as well)) the pain of creating strongly typed collections has been soothed. -Boo Show quoteHide quote > I do find I am running into a bit of a grouping issue, as to : > when I write a bunch of custom generic functions where to store them. > For example I like to do a lot of things in arrays. So I have a > function > that returns an array position of a > value, another that removes a certain element and redims the array and > so > on. > Currently I added / created a MiscLibrary Module and am most likly > will have > to split those up > and group them accordingly as I create more and more. > -That way Im assuming if later I try to create another program and > these > functions can be re-used I am > in effect creating my own Library of Functions and Subs. > -So I can just add this Module to a different Project later. > I just started in VB.net so I really havnt run into your headaches yet > of > huge programs, but i have run into them > with other languages and software created. So I am kinda following > the same > rules there and slowely re-writing them > for vb. > Thats why I guess I sometimes am looking to do something really > "weird" in > VB that seems "funny" to some of you when > I ask some questions here. > Just trying to code the same way in 1 langauge as in the other, and > then > slowly VB'ise it. ( If VB'ise is a real word ) > Books can only take you so far. I think its the experience of another > programer that does make ur life a lot simpler. > > So thanks for all the help so far. > And if anyone needs help with any old 4Gl languages... like ProIV... > Ask > away :-) - But thats a different newsgroup. > M. > > "jeff" <jhersey at allnorth dottt com> wrote in message > news:exy%23laQzGHA.4396@TK2MSFTNGP04.phx.gbl... > >> Cor, >> >> Agree...calling out ... is over used in a lot of cases ... >> >> ie... >> >> MyMath Class >> >> MyMath.AddNumbers(aNumber1,aNumber2) as Doublle >> ReTURN aNumber1 + aNumber2) >> End ... >> Agree, if can be overused ... I have seen it too... >> >> Agree Best Practice is the situation it is done for ... but I have >> yet to find a situation where a single code segment is best practice >> for a solution to a project . >> >> my point was to identify starting points to decide where and when to >> call out to other functions / classes and so on ... when you have >> another problem to solve you have a case for another 'function' >> 'class' 'object' whatever ... this does not mean a decision you need >> to make ... >> >> ie... >> >> If a = b then >> .... >> Else >> ... >> End if >> should not be replaced with >> >> if MyCompare(a,b) then >> ... >> else >> ... >> End if >> Unless there is more business logic in the comparison ....because if >> there is more business logic, this becomes a problem to solve rather >> than a desicion... >> >> JEff >> >> "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message >> news:OPyuRKQzGHA.4968@TK2MSFTNGP05.phx.gbl... >> >>> Jeff, >>> >>> I have seen programs that did more calls (whatever that were) than >>> actual things. >>> >>> I think that Best Practise has to do with the situation it is done >>> for. >>> >>> Cor >>> >>> "jeff" <jhersey at allnorth dottt com> schreef in bericht >>> news:udl6ZjPzGHA.4452@TK2MSFTNGP05.phx.gbl... >>> >>>> Boo, >>>> >>>> the boring part to some...is the exciting part to me... >>>> >>>> being a 'self educated' / 'self-learned' programmer ... many of my >>>> 'rules' / 'standards' have been brought about by trial and error... >>>> It is nice to read that some of the things I do, others do as well >>>> ... many times, I have hired (and fired) college and university >>>> grads simply because they do not know how to code ... your code >>>> needs to reflect your problem solving skills...if you tackle a >>>> problem as a whole and do not plan...you end up with one big sub >>>> routine with a few calls out to other modules / classes / functions >>>> which are so tightly connected to the current problem that 're' >>>> usability is out the window - you spend more time trying to solve >>>> the large problem in one fare swoop - you end up wasting time, >>>> spinning your wheels, bangin your head off the wall ... However, if >>>> you break you problem into small, managable tasks and tackle each >>>> task as a seperate, isolated project ... and break these smaller >>>> projects into task...and tackle each task as a seperate, isolated >>>> project ... for next til parent project is done ... yet get the >>>> pictue ... >>>> >>>> Now to the point... >>>> >>>> your code should reflect your approach to solving the problem... in >>>> Boos examlpe... >>>> >>>> - focus on setting up datatable columns ... prime focus ... who >>>> cares about the beginning and end ... you need to focus on setting >>>> up datatable columns ... what you do after that is another problem >>>> ... how you populate them is another problem ... Once you can >>>> setup datatable columns, move on ... >>>> >>>> - fetch some records ... prime focus ... how do i fetch some >>>> records ... need to connect to database ... need to query a table, >>>> call a stored proc, query a view ... oops... this is a bigger >>>> problem with smaller tasks ... 1. connect to database - focus / >>>> sovle ... 2. query a table for records - focus / solve ... 3. query >>>> a stored proc - focus / solve ... and so on. >>>> >>>> - maniputate the data ... on the surface ... simple ... user >>>> changes data ... done ... if there are other processes ... looking >>>> / comparing / calculating ... isolate each routine - focus / solve >>>> ... for example ... need to maniputate dates and phone numbers ... >>>> focus on date validition, date formatting, date constriants ... >>>> done ... focus on phone numbers ... validation, formatting, >>>> constraints ... done. Now, anytime you need to 'manipulate dates' >>>> ... you re-use this code ... done. >>>> >>>> - toss back to database ... prime focus ... need to connectting to >>>> datasource ... database, done already , xml file or other source >>>> ... focus, code it ... >>>> >>>> So, in the above, as Boo has already mentioned, you have at the >>>> very least 4 distinct code blocks...with four distinctly different >>>> responsibilities ... breaking code in to logical classes, >>>> functions, procedures and so on ... is a lot better than a code >>>> segment that needs 40 lines of text to explain 39 lines of code >>>> .... to me, over commenting is a bad thing... if you find yourself >>>> writing just as much comments as you do code ... you need to >>>> rethink your design approach. Now, sometimes you need to add a >>>> bunch of comments to explain something, or refresh your memory as >>>> to why you have implemented a certain approach ... this is fine ... >>>> but should be the exception and not the rule in commenting your >>>> code. >>>> >>>> Boo...I did bore...but to some, knowing others practice as you do, >>>> validates your efforts...and makes you want to talk about it. >>>> >>>> Thanks. >>>> Jeff. >>>> "GhostInAK" <ghosti***@gmail.com> wrote in message >>>> news:c71747b42e4888c89a83d12a3152@news.microsoft.com... >>>> >>>>> Hello Miro, >>>>> >>>>> Myself I'm a big fan of self-documenting code. Keep in mind there >>>>> is a right way and a wrong way to do this. In order for your code >>>>> to be self-documenting you have to plan.. you can't simply sit >>>>> down and start typing code. To make this work you MUST have >>>>> descriptive names for EVERYTHING. Something named "Cxn" or "Cnn" >>>>> just aint gonna cut it. Use fully descriptive identifiers like >>>>> "tConnection". Also, keep your function SMALL. As a general >>>>> rule, anything over 20-30 lines of code in a single function is a >>>>> bad thing. Lets say you have to set up the datatable columns, >>>>> fetch some records, manipulate them, and toss them back into the >>>>> database.. This is a MINIMUM of 4 different procedures (one for >>>>> each action).. and off the top of my head I can thionk of several >>>>> helper functions that would go with them. Yes, functionally you >>>>> could roll the whole thing into a single procedure.. but it >>>>> becomes hard to read and maintain then.. and this rant is about >>>>> self documenting code. If you break it into 4 separate functions >>>>> there's no need for comments in the code describing what blocks of >>>>> code does. A function called "SetupDataTable" obviously prepares >>>>> a datatable prior to filling it with data. >>>>> >>>>> I've got a whole philosophy for design and implementation of >>>>> software.. I wont bore anyone with it unless ya ask me to. >>>>> >>>>> Enjoy, >>>>> -Boo >>>>>> I guess this brings up another question. >>>>>> >>>>>> Do you just have a comment block on commenting what the Class / >>>>>> functions ... etc do? >>>>>> >>>>>> For example I usually do something like this: >>>>>> >>>>>> PUBLIC CLASS >>>>>> ' This class blablablablbl alblablla alblalba >>>>>> ' balblal lbalbalb llablablaa >>>>>> ' and some more bla's >>>>>> END CALSS >>>>>> What do you guys put in there? Or do you even comment your >>>>>> classes / functions like that? >>>>>> >>>>>> -Just wondering >>>>>> M. >>>>>> "Rex" <rbas***@cfl.rr.com> wrote in message >>>>>> news:1a1cf2lgv44f1fcolj4k3p73i8tcss2hl7@4ax.com... >>>>>>> Thanks, Cor, Boo, and Wolfgang, >>>>>>> Boo, thanks for your thoughtful reply - you make an excellent >>>>>>> point >>>>>>> about having some excellent standard for organizing - I shall >>>>>>> try to >>>>>>> implement that. >>>>>>> And Wolfgang - Thanks very much - CodeRusht looks like a >>>>>>> fantastic >>>>>>> product - which I think will REALLY help me in my coding. >>>>>>> Regards, >>>>>>> Rex >>>>>>> On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer" >>>>>>> <ha***@DELETETHATsysdat.at> wrote: >>>>>>>> Have a look at coderush >>>>>>>> www.devexpress.com >>>>>>>> wolfgang >>>>>>>> "Rex" <rbas***@cfl.rr.com> schrieb im Newsbeitrag >>>>>>>> news:qr3bf2dipsm90m4dldn7k5qmkfoptuukh0@4ax.com... >>>>>>>>> Hi All - I have a question that I think MIGHT be of interest >>>>>>>>> to a number of us developers. I am somewhat new to VIsual >>>>>>>>> Studio 2005 but not new to VB. I am looking for ideas about >>>>>>>>> quick and efficient navigating within Visual Studio 2005. >>>>>>>>> Let's say your project (or solution) has dozens of forms and >>>>>>>>> hundreds or even thousands of routines. >>>>>>>>> >>>>>>>>> Two Questions: >>>>>>>>> >>>>>>>>> 1) BUILT-IN to Visual Studio 2005. What ideas do you have to >>>>>>>>> quickly >>>>>>>>> navigate? For example, bookmarks help. But what other ideas do >>>>>>>>> you >>>>>>>>> have? How do you quickly get to some routine you haven't >>>>>>>>> looked at >>>>>>>>> in >>>>>>>>> a while and you're not totally sure what the name is? Is there >>>>>>>>> some >>>>>>>>> easy way to see ALL the names of ALL the routines in a project >>>>>>>>> (if >>>>>>>>> there is, I'm showing my ignorance here!) Here is what I know >>>>>>>>> - to >>>>>>>>> start out with: >>>>>>>>> * Bookmarks are useful. Normally they disappear when you close >>>>>>>>> your >>>>>>>>> files/project - but if you leave the files open and close the >>>>>>>>> SOLUTION, then bookmarks are saved. >>>>>>>>> * Ctrl-minus and Ctrl-Shift-minus takes you back and forward >>>>>>>>> among >>>>>>>>> recently edited areas. >>>>>>>>> Anyone else have further ideas? >>>>>>>>> 2) Any 3rd-party add-in's that might help? >>>>>>>>> Thanks, everyone! >>>>>>>>> >>>>>>>>> Rex >>>>>>>>> Hi!
I use always xml-docs. Have a look at www.roland-weigelt.de/ghostdoc . Its a real timesave wolfgang Show quoteHide quote "Miro" <miron***@golden.net> schrieb im Newsbeitrag news:%23A38IlIzGHA.4844@TK2MSFTNGP04.phx.gbl... >I guess this brings up another question. > > Do you just have a comment block on commenting what the Class / functions > ... etc do? > > For example I usually do something like this: > > PUBLIC CLASS > ' This class blablablablbl alblablla alblalba > ' balblal lbalbalb llablablaa > ' and some more bla's > > END CALSS > > What do you guys put in there? Or do you even comment your classes / > functions like that? > > -Just wondering > M. > > > "Rex" <rbas***@cfl.rr.com> wrote in message > news:1a1cf2lgv44f1fcolj4k3p73i8tcss2hl7@4ax.com... >> Thanks, Cor, Boo, and Wolfgang, >> Boo, thanks for your thoughtful reply - you make an excellent point >> about having some excellent standard for organizing - I shall try to >> implement that. >> And Wolfgang - Thanks very much - CodeRusht looks like a fantastic >> product - which I think will REALLY help me in my coding. >> Regards, >> Rex >> >> >> On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer" >> <ha***@DELETETHATsysdat.at> wrote: >> >>>Have a look at coderush >>>www.devexpress.com >>> >>>wolfgang >>>"Rex" <rbas***@cfl.rr.com> schrieb im Newsbeitrag >>>news:qr3bf2dipsm90m4dldn7k5qmkfoptuukh0@4ax.com... >>>> Hi All - I have a question that I think MIGHT be of interest to a >>>> number of us developers. I am somewhat new to VIsual Studio 2005 but >>>> not new to VB. I am looking for ideas about quick and efficient >>>> navigating within Visual Studio 2005. Let's say your project (or >>>> solution) has dozens of forms and hundreds or even thousands of >>>> routines. >>>> >>>> Two Questions: >>>> >>>> 1) BUILT-IN to Visual Studio 2005. What ideas do you have to quickly >>>> navigate? For example, bookmarks help. But what other ideas do you >>>> have? How do you quickly get to some routine you haven't looked at in >>>> a while and you're not totally sure what the name is? Is there some >>>> easy way to see ALL the names of ALL the routines in a project (if >>>> there is, I'm showing my ignorance here!) Here is what I know - to >>>> start out with: >>>> * Bookmarks are useful. Normally they disappear when you close your >>>> files/project - but if you leave the files open and close the >>>> SOLUTION, then bookmarks are saved. >>>> * Ctrl-minus and Ctrl-Shift-minus takes you back and forward among >>>> recently edited areas. >>>> Anyone else have further ideas? >>>> >>>> 2) Any 3rd-party add-in's that might help? >>>> >>>> Thanks, everyone! >>>> >>>> Rex >>>> >>> > > > For example I usually do something like this: Commenting is very important. But as already mentioned, structured XML > > PUBLIC CLASS > ' This class blablablablbl alblablla alblalba > ' balblal lbalbalb llablablaa > ' and some more bla's > > END CALSS comments are better way to do it. You can then automatically generate IntelliSense info, MSDN-like documentation and F1 help. There are various ways to achieve this, see for example my signature :) -- Peter Macej Helixoft - http://www.helixoft.com VSdocman - Commenter and generator of class documentation for C#, VB ..NET and ASP .NET code I find that enclosing groups of related functions using the #Region
block helps in navigation as well. Forcing yourself to group things while creating them adds a bit of structure that is useful long after you are familiar with the code. Being able to collapse regions while jumping between 2 is also good. 
Other interesting topics
Concurrency violation at update
A Service in VB.NET 2005 using a form ? How to dynamically instantiate a base calss (w/ args to constructor?) Where can we buy VB.net? How Microsoft does it? do event Date/Time problem No equivalent control VB6 to VB.Net ActiveX Document DLL (VBD) Inquiry... crystal report question |
|||||||||||||||||||||||
