My little project tend to grow… What kind of techniques have you developed, in a personal matter, to not have a mental brain meltdown for all the names to remember or different places to look for and to put code!?
Everything tend to be pretty confusing fairly fast, to look for all kinds of names all over the project. Names of buttons, fields, database fields… All.
Of-course, I also have developed a “personal style of programming”… but I feel I need some inspiration to also develop this talent in a more positive and efficient direction!
I presume you are a novice to Xojo and/or app development in general?
I am developing a large project and I am finding it easy to navigate.
Things I often do (which you may already do):
Create a naming convention. There is no ‘wrong’ way as long is it works for you. People tend to recommend for example using a capital letter at the start of a class name and using a non-capital letter at the start of local variables (defined in code). What I am trying to say is people recommend you try to distinguish different the scope of a particular variable, class, method, etc. Do not get too stumped over remembering naming conventions though.
Following on from my last point (with naming conventions): categorise items using naming conventions. For example, you could categorise windows by starting names of windows with ‘Win’. You can categorise in all kinds of ways. Be creative and have fun.
Search for project items with the navigator’s search field. This is not for searching through code, notes, the contents of project items etc but it is for searching through names. This is where your naming convention comes in handy (not with casing - I do not think the navigator’s search is case-sensitive).
Use the main search tool and write comments in code or notes that might help you find your way around the project.
Use folders and do not forget about sub-folders. Grouping items with folders is great organisation but grouping by folders within folders is far better (especially for large projects).
I’ve done web development for the past 20 years and Xojo more or less for the past five years… But I haven’t been very productive, it’s true.
I feel my sort of small project is getting tricky to work with because I tend to forget all parts as it contains.
Yes, I also think more app-production will help. It’s natural. More work = more experience.
But the great feature would be if you could have the same project open in more than one views!
Then you can look at the design of your window and writing the code to the window while looking at the name of the fields, buttons, boxes and all you need.
For current, you need to go back, forth, back, forth, back forth…
But again, this is my point! Maybe I’m doing all this wrong!?
I truly believe the majority of all the users on this forum daily spend much time on project either larger or much larger than what I’m doing!
I hope this post made it more clear what I’m looking for or asking for!!
(I’m not stupid, just lazy…!)
[quote=120191:@Jakob Krabbe]But the great feature would be if you could have the same project open in more than one views!
[/quote]
Use File->New Workspace to open a new view into your project. And be sure to use “Open in New tab” as well.
The Pragmatic Programmer webinar might have some tips you can use to be a more efficient developer.
Project organization is important. For web apps we have a generic ‘Pages’ folder with sub folders for each area. Then we have classes and images folders. It might take you a few projects to figure out what works best for you. The point is that you want to able to look at your project structure and be able to guess where the object you want is at.
For Pages, and Containers, I highly recommend NOT using the default control names. Nothing worse than seeing TextFieldX (x being a number) and not knowing what it is and having to refer to the layout. Awful waste of time. txtFirstName is very descriptive and, for us, the txt tells me it’s a text field or area. We use prefixes on our controls to make it easier to tell what the object is in code.
Variable names are similar. We do NOT believe in hungarian notation but we do use a data type prefix. Dim s as string is less descriptive than dim sFirstName as string and so on. Object instances tend to have an o prefix. dim oName as new MyNameClass is as descriptive as possible. Arrays have an ar prefix. arsNames tells you it’s an array of strings of names. If we had an array of MyNameClass it would be names aroNames.
The point is to be able look at your code and at a glance be able to tell what everything is.
Thank you Paul very much!! Now we’re talking…!!
Scrolling can be terror and confusion may be total. Same with concentration…!
Bob!
I truly believe in Hungarian style naming and I am crazy enough to mane my fields such as intID, strFirstName and so on.
However, I know for many years that many heavy hard core programmers don’t use and don’t like such names.
I’ve considered to change this structure but I’ve not yet reached the point where I see the glory…!
I’m still waiting for someone to enlighten me!!
[quote=120211:@Jakob Krabbe]I’ve considered to change this structure but I’ve not yet reached the point where I see the glory…!
I’m still waiting for someone to enlighten me!! :-)[/quote]
Well, we are Xojo consultants so we work on dozens of projects every year. The naming conventions we use make it easier to figure out code that we did for client x four years ago. It’s not perfect but when everyone in the organization is using the same naming convention it makes it easier to have different developers work on things.
When it’s just you it’s a little different and we’ve refined our style over the years. What I did 10 years ago is not nearly as readable as what I do today. The school of ‘hard knocks’ has a harsh teacher.
I’ve done web development for the past 20 years and Xojo more or less for the past five years… But I haven’t been very productive, it’s true.
I feel my sort of small project is getting tricky to work with because I tend to forget all parts as it contains.
Yes, I also think more app-production will help. It’s natural. More work = more experience.
But the great feature would be if you could have the same project open in more than one views!
Then you can look at the design of your window and writing the code to the window while looking at the name of the fields, buttons, boxes and all you need.
For current, you need to go back, forth, back, forth, back forth…
But again, this is my point! Maybe I’m doing all this wrong!?
I truly believe the majority of all the users on this forum daily spend much time on project either larger or much larger than what I’m doing!
I hope this post made it more clear what I’m looking for or asking for!!
(I’m not stupid, just lazy…!)[/quote]
‘Creative is not always good!’, true but that does not mean you shouldn’t be creative.
For Desktop apps we use the following folders to group common items.
AppProcs - these are modules that are specific to the application being developed
AppWindows - these are windows specific to the application being developed
AppMenus - these are menus for the application
AppToolbars - these are app specific toolbars
AppImages - these are images specific for the application
FileTypeSets - you know what these are
DefaultWindows - these are Windows that are included in all applications and copied from what we call our basis “Starter App”
ExternalProcs - these are external modules that contain methods used in all our apps
ExternalClasses - these are external classes that are used in all our apps
ExternalImages - these are images that are used in all our apps
We use a two character code to identify controls. The first 2 characters tell you what kind of control it is:
For example:
tf = textfield, ta = textarea, cb = combobox, ck = checkbox, pm = popup menu, etc, etc.
Definitely makes development much easier when you know where to find things and can easily identify what it is.
When it’s just you it’s a little different and we’ve refined our style over the years. What I did 10 years ago is
not nearly as readable as what I do today.
Well… The problem for me is that my code was perfect to read 10 ago and still is today!
That’s why it’s difficult to improve…
For example:
tf = textfield, ta = textarea, cb = combobox, ck = checkbox, pm = popup menu, etc, etc.
That makes sense. Thank you!
The Pragmatic Programmer webinar might have some tips you can use to be a more efficient developer.
Thank you Paul for a great show! I’m impressed!
However, I knew all these things already…
So, in such sense, I was little disappointed.
However, I have a suggestion you didn’t mention and I can write to you in person. Maybe it’s not so important!? (??)
I will look into:
Project tracking tool. Maybe it can be good for me!
IF … vs. SELECT CASE. I’ll be more observant.
FOR EACH… I believe I use when appropriate.
“Be yourself! Unless you’re a ■■■■!”
That’s a good one!
I think the most valuable from this session for me is that I now can entitle myself as a pragmatic programmer or pragmatic person because it’s how my life has been for the past 20-30 years…
The next blog post at www.bkeeneybriefs.com will have our naming standards. It’s currently scheduled to go out tomorrow (Friday) morning. Keep in mind these are fairly loose guidelines since we all break them when we need to.
Personally, I don’t think it matters what naming convention you use as long as you’re consistent about it. Some will argue against variable naming conventions since Xojo is strongly typecast but I still think it helps to have standards.
I can tell that our entire team uses the standards because I can’t guarantee (usually) which team member will be working on any given project. Because we all use the same naming it’s much easier to interchange developers.
Naming conventions don’t replace comments. But at least you won’t have to waste time telling me what i is if it’s iIndex or iLoopIndex.
When naming a method It’s generally a combination of at least one noun and one verb.
The natural english way to write this is usually to put the verb first and then the noun as in RetrieveCustomer
But by changing the order to, NounVerb you’ll have all the methods relating to customer adjacent to each other in the listing of methods.
Since making an alteration to one method affecting customer will often require alterations to the others I find this makes life easier, e.g
CustomerRetrieve
CustomerDisplay
CustomerSave
[quote=121097:@john bowen]When naming a method It’s generally a combination of at least one noun and one verb.
The natural english way to write this is usually to put the verb first and then the noun as in RetrieveCustomer[/quote]
I do it that way too, but sometimes I would like to go back to VerbNoun as I did in the beginning years ago, because the source code reads more like sentences. It would be great to have to possibility to rearrange class and module elements in the IDE navigator in a non-alphabetically order.
a lot of things already said. I want to add just to more:
Make use of external saved objects and make somebody responsible for “his” object to keep it clean and useable in different projects.
Instead of adding more methods or functions try to combine them in centralized single functions making use of optional vars.
Dim your vars all together n block and not everywhere spread out.
If you deal with a team, make common rules or guidelines how data is stored on disk, or objects should be named. Try to establish kinda common snippet base of templates.
Try to use search box on upper left corner of IDE, I do not wanna miss it anymore.
Software developing is 45% organisation, 10% programming and 45% debugging, testing…
