In my experience code behind UI can easily get ugly, and inorganized, e.g. long functions, lots of variables etc.
How do you manage the code behind UI?
The MVC pattern is often used to impose some structure and organisation.
Following the principles of SOLID OO design and similar ideas helps.
It depends on your programming-language.
Threre are a lot of QA-Tools for different languages. Have a look at wikipedia
Which languages and techniques do you use?
One solution is to use 'immediate mode' UIs. It basically boils down to only caring about the UI element you're currently focussed on and binding the variables with data-side app variables. This is the opposite of retention mode UIs
Great video here.
Related
I have a little hard time with all of those design patterns and things that could help me write maintainable code, clean and reusable.What are the most used design patterns in your Apps? A list or something with them will be nice, there are a lot of design patterns and I dont really know with what should I start.
You don't have to consider that much about design patterns if you follow 'Laravel' pre-defined way. they kinda have defined almost everything by following those design patterns.
You can refer these articles as a start.
https://github.com/alexeymezenin/laravel-best-practices
https://www.innofied.com/top-10-laravel-best-practices/
And most importantly Official documentation.
https://laravel.com/docs/7.x
The most import thing you need to consider when using 'Laravel' try to use 'Laravel' as much as possible. (Instead of pure php)
I used to have a nice set of coding standards I could print for coldfusion that was almost a framework but much looser with some code examples. Like teh use of createObject, more cfscript, error and message integration, Application.cfc usage and examples. Also seperation of buisness (actions) and display using cfincludes to make an index.cfm page 'a generator' of many actions leveraginf cfswitch/cfcase...etc. I am looking for some doucmentation or anything that I can print our and sit on my desk and refer to so my coding stays clean. Any help from the community would be very much appreciated.
Although rather dated, You may find what you are looking for among the many posts listed under the "Coding Guidelines" section on the "Articles" page of the MDCFUG - Mayryland ColdFusion User's Group website.
Here are some other options:
Univ. of Maryland ColdFusion Programming Standards
Sample Applications Methodology Guidelines provided by Adobe.com
SBA ColdFusion Programming Standards contains 126 pages of coding standard written for the U.S. Small Business Administration to insure security, promote code re-use, easy readability, and easy maintenance.
Oregon Health & Science University - Coding Guidelines which contains a number of GOOD versus BAD coding examples.
I'm unaware of any "official" Coldfusion specific coding standards. Where I work we collectively came up with our own based on many years of experience working with the language. A simple one for example is to use camel case. From what I've seen camelCase is preferred over snake case in Coldfusion, so as a rule we have:
In general, for files use lowerCamelCase starting with a lower-case letter, except for CFCs which should start with an upper-case letter as they represent a class in ColdFusion.
We have other standards broken up under headings such as:
Variable Naming
Operators
Scopes
Functions
ColdFusion Native
Functions
Indentation
......
I am looking for some doucmentation or anything that I can print our
and sit on my desk and refer to so my coding stays clean.
In addition to this I recommend you create a set of generic code snippets, such as you can use in Eclipse, that conform to any standard you decide to go with. These can then be easily distributed among team members, helping to keep things consistent as well as saving typing time.
I realise this is quite an old post now, but thought it would be worth mentioning http://wiki.coldbox.org/wiki/DevelopmentBestPractices.cfm. I think this is a good set of standards for writing CFML.
I find myself in conflict, regarding which code style I should follow when using a different C language.
Currently I am doing work (different projects) in C++, C# and Objective-C
I noticed there is a lot of discrepancy in the conventions basic frameworks follow. Generally, I don't think it's a bad idea to adhere to these conventions, as it makes code feel more "integrated" into the environment. However it is hard for me to remember all the differences and apply principles correctly.
In C# for example, all methods of a class start Uppercase, while Objective-C seems to prefer camelCase style methods.
What tactic would you choose:
One style to rule them all (as far as applicable)
Stick with what is common in the given environment
I do especially like the google styleguides, which seem to recommend the latter. However I disagree with them on using spaces instead of tabs and their indentation in general (e.g. methods on same level as class etc.)
I think you should stick to the "accepted" styles for each language. My rationale for that is that I think it would be much easier to recall what environment you're in when you have to think in the style used for that language. It will also be much easier for someone who is familiar with that environment to look at your code and feel more comfortable with the style and formatting (i.e. less chance for them to misunderstand what they're looking at).
My rule with porting code is: Don't touch it unless you have to.
My rule with modifying old code is: Use the style of the file.
Outside of those two situations, things like coding standards and perhaps your own opinion on good style can come into play.
Is there is a generic, widely understood term for GUI elements. I have programmed so many GUI toolkits, I couldn't tell if Windows-only programmers know what the Java crowd means when they talk about widgets. Does a GTK+ user know what a control is? And does anybody besides me remember gadgets?
Qt uses widgets, Swing uses Components. Most gui programmers will understand what you mean when you say a scroll-widget/component.
As component is to generic, I'd say: Visual component.
It just describes exactly what it is: a visible, self-contained element, that does some well-defined task.
According to my Human-Computer Interaction teacher and to the this HCI manual the name is "widget".
Component?
I would say "element". "Component" evokes COM object for me.
I don't think there is one term to cover it, but window, component, widget and control are all in widespread use, so I would think most developers understand them all, although they may mean slightly different things in different frameworks (i.e. which is the lowest common class/component in the framework).
Actually, I think GUi element (or graphical element/interface element) is a pretty good catch-all term.
As noted in this SO question, naming is hard, and that makes this question very much program-related!
As specified in the javadoc of org.eclipse.swt.widgets.Widget, a Widget refers to "user interface objects" in general.
So it might be more precise than the too-generic term "component".
Symbian (currently) uses controls, but S60 is in the process of moving to QT so this is likely to move to widgets.
I'd suggest that you stick to the convention of your GUI framework. That way people who invested the time to learn the framework will know what you mean, and those who don't wouldn't know what you meant till they did anyway. If it's for a framework independent article or some such, define what you mean either at the start or in an appendix (for example: control - a GUI element, also commonly known as component, widget, etc).
A recent question about StyleCop alerted me to the use of tools to enforce coding style. I would feel very annoyed if I were required to run one of these tools while I was developing. Do people really find them useful? Why or why not?
Everyone that has answered so far has indicated that they think that style/formatting rules are useful, and I am in 100% agreement with that. But what about using a tool for enforcement, rather than a style guide and regular code reviews? Have people found that useful in practice? Why or why not?
Yes, it's very helpful - particularly in large projects. It means you can go to anyone else's code, and it won't look alien to you. This means that people are more portable across projects, which gives a lot more flexibility - both for the person and the company.
The downside is that a lot of time can be spent arguing over which style to use.
There is a difference between a Coding style and a Formatting style.
A coding style enforces good practices.
the body of a 'IF' statement must be wrapped in opening and closing curly brackets
A formatting style is how the code looks.
where the '{' comes in an 'IF' statement.
In a team environment;
a good formatting tool will allow all the developers to see the code the way they want to see the code.
a good style tool will insure all the code follows the same guidelines
I like the concept of StyleCop, although I don't really care for a lot of the rules. Style is just so subjective that I find myself struggling to firmly decide if it should be part of our process or not. I really would prefer to see the team with a unified style, though, which is why I am so torn.
Obviously, the flip-side of the equation, with a tool like FxCop (or Code Analysis for fellow TFS users) is more based on practices, so the decision becomes more technical than personal and stylistic.
If style refers to formatting (like '{' must be at the end or at the beginning of a line), it can be very annoying, especially if merges are involves and if that style is not strictly enforced for all developers.
If style refers to 'good practice" (like the body of a 'if' statement must be wrapped in opening and closing curly brackets), it can be actually very useful.
I think in a large team, a uniform coding style is essential. Having some standard helps with maintainability, in that a new developer can be brought on to maintain old code, with minimal learning curve.
As far as enforcing styling differences (such as where the '{' comes) can be very easily be accomplished by automated tools, without imposing on the development process too much. Eclipse and Visual Studio both have a very rich set of options to format your code automatically based on a large set of options.
Restrictions on programming or formatting style might help reducing friction in a team of more than one person.
Restrictions on language features (especially using only a subset of C#) can help you concentrate on the problem domain instead of having to deal with an overwhelming number of concepts. This does matter if your software has to be robust and thoroughly understandable.
Regards,
tamberg
If you are using a version control system, it can get very ugly if every developer reformats the code towards his own preferences whenever he touches a file. In a place where the developers don't have the necessary communication skills, Wikipedia-like edit-wars can ensue if each developer passive-aggressively sticks to "his" standard.
Overall, manual reformatting also leads to more conflicts on checkins if two people work on the same file.
So if you are using a VCS, I'd even recommend enforcing formatting rules. Enforcing style rules can lead to better code quality.