Related
Is it possible to use the results of studies made into human learning in order to identify how code might be laid out to improve comprehension?
Code layout wars almost always end up defending consistency and the prevailing style, but could there be ways of laying out code that are provably better than others?
What is Code Layout to you?
On one hand there are these evil things called coding conventions, which place everyone in a corset. I loathe these and I believe we're far behind schedule to eliminate them. We can parse code and I do not understand, why our IDEs still display code based on the very textual format it is stored in. What's so hard in allowing each user set up his layout prefences and the IDE displays all source code accordingly? Most IDEs offer some kind of auto-format option, yet you often cannot customize how it works.
However, a far more interesting approach is whether our current point of view on source code is suitable for learning at all. Projects like Code Bubbles are pioneering a new way there. And then of course, we have model-based approaches which are often more accessible from a learner's point of view.
I'm afraid there is no definite answer to this question. In fact, if you can write down a detailed answer for it, don't forget to claim a PhD for it ;)
Could there be ways of laying out code that are provably better than others?
Yes. This problem was studied extensively in the 1980s. You could read all about it :-)
A good university library should have Human Factors and Typography for More Readable Programs by Ronald M. Baecker and Aaron Marcus, published by Addison-Wesley in 1990.
I think this comes down to personal preference. I prefer to have very little shorthand in my codes, I think it's the best way for me to comprehend what's going on inside my codes without having to remember which order shorthand works in, maybe my memory is bad.
Possibly it would be a good idea to use such studies say on a class of students learning to make codes the same way, but everyone develops their own way of coding after time. There are already "provably better ways" as laid out by the best practice suggestions for each language.
Interesting question.
The biggest problem for me with understanding code is not code layout (however code should be formatted consistently) but following execution order. In complex OO source code it is hard to see the complete code involved in execution.
I think that IDE functions can help a lot for code understanding. For me (as a java developer) tools like the Call Hierarchy view in Eclipse and Mylyn are very useful.
An interesting (new) way of understanding code is shown in the Code Bubbles Project.
I expect more steps in these directions in the future.
I think teaching programming may have given me some skill in this area, because to get ideas across to students you have to keep things small, simple, and introducing only one concept at a time.
However, as one of my colleagues used to say to his students:
Teaching is my job.
Learning is yours.
As that applies to programming, I think it is the programmer's responsibility to write the code so as to educate others as to what he/she is trying to accomplish, but there is no code that will be clear to readers who do not put in effort.
First of all, I do not believe this belongs on Superuser. This belongs here because it is strictly programming related.
What I am looking for is a program that will visualize(draw it on the screen or something) how programs create variables, make pointers from the stack to the heap, variable names and contents, and so on.
Kinda like a diagram/flowchart thing, but automatically drawn for you.
Does such a thing exist?
EDIT: i just came across this topic: Visualizing the code involved in an action?, that's not what I'm looking for, I'm talking about some really graphic and dynamic.
EDIT:
I found 1 thing, but it's not really great and kinda old.
jElliot, demo can be viewed here: http://www.youtube.com/watch?v=f5ahEgu5Ba0
If you are working on one of the UNIX platforms, you might want to look at DDD.
Have you ever seen Ben Fry's work in this space?
Say for instance I'm going to do some seat of my pants coding adding a feature to an enterprise app. What are some good examples/tenants/cardinal rules a person can follow for making a fairly complex setup/config screen not look like feet.
What I'm looking for is along the lines of "Don't put one thing in a group box". But I'd also like some help with symmetry if anyone knows what layouts are most likely to achieve a relative amount of good looks that would be helpful.
Here's a cardinal rule you asked for: line up the controls vertically /horizontally and equally space the various related elements. And use correct spelling on your labels!
We've all come across screens where there are misaligned controls (even a couple pixels is noticeable) or misspelling on labels. When this happens to me I can't help but subconsciously look for other mistakes, plus it decreases my confidence in the application I'm using!
This is actually a huge topic. I frequently go to the Microsoft UX Guide for reminders on how to do this.
Some basics:
Make your app read like a book: left
to right, top to bottom
Use goal-oriented language instead of
technology oriented language
Not a cardinal rule but a great resource:
Apple UI Guidelines (good info for any OS)
EDIT: Re: achieving symmetry - things don't have to be perfectly symmetrical, but you want a feel of balance. Take a step back and get a sense of whether the page or form feels like it's leaning/falling to the left or right.
E.g., with stackoverflow, the main content is to the left, but it's nicely balanced by the extra stuff on the right.
I find that paper is my friend. I like to write out a list of objectives the form has to accomplish, and then sketch the form by hand, labeling the parts. Drawing it out lets me get away from making sure it looks perfect and that everything is aligned just right, and lets me focus on making sure that all the components I need are placed, hopefully somewhere logically. It also forces me to lay out the UI twice, so by the time I open my UI designer, I've already designed the form once and you hopefully know what I am doing
Some basic rules for you.
Try to make effective use of whitespace. Don't cram everything together in an effort to get as much stuff on screen as possible. This will make grouped controls more clear and text more legible.
Basic typography. Limit your use of fonts to 1 or 2. Don't use bold too much or it loses its emphasis.
The same goes for colours. Don't use too many, the fewer the better most of the time.
Don't just use icons to save space. Tiny icons with no explanation are useless.
Copy. Not wholesale of course, but if you are not well-versed in UI design yourself, it makes sense to take elements of interfaces you know work and apply them in your own designs.
Be clear about the purpose of the interface. How does it fit within the broader application for example? And what are the specific objectives you are trying to satisfy with it?
Get people to test it for you, early and often. I don't know what setup you are working with, or what kind of organisation you are in, but getting some kind of human feedback on your work will always be helpful, even if you lack the time and expertise to conduct proper usability evaluations.
Since you use the term, "seat of your pants," I'm assuming that you don't want to spend too much time on the UI. If you are willing to devote some time to the UI, you may want to look into custom control or UI development that will suit your situation. Like Firefox's Options UI or the .NET project properties in Visual Studio 2008.
If you are looking for something using standard controls, it is probably best to separate out different sections of related items into tabs or some other type of stacking control (i.e. Ribbon control). A good example of the tabbed version would be the Notepad++ Preferences UI. Many other programs use a similar scheme.
The best way to get a UI that makes sense is to follow Joel's advice:
Eat your own dog food.
Do it a few times to your own UI, and you'll notice some things you didnt think of intially.
I've found that a really good test is getting someone non-technical to use your GUI. Watching someone use it for 5-10mins normally gives me a very good idea about what is/isn't easier to understand.
This series by Joel Spolsky is a pretty good read and Jakob Nielsen's stuff Usability and Web Design is pretty useful.
Specific rules I try and use are:
Put items in logical groups
Line everything up
Use sensible images/icons
Spend 5-10 mins thinking through why things are the way there are
Only use words that make sense to the user not to you!
Start from the setup/config UI of an existing application that you feel is both simple and usable.
Most tenants/cardinal rules apply to UI in general and fill hundreds and hundreds of pages in UI design and HCI books, so you probably want to just work your way by example for now, while trying to capitalize on existing user experience (habits), i.e. obeying the rule of "least surprise": e.g. if your application is a Windows application, use the Installation Wizard pattern, if it's an ncurses app for a particular flavor of *nix follow the style of that particular OS's actual installation UI, etc.
You might be interested in the book "Don't Make Me Think," (author's web site) or "About Face 3.0". Both come highly recommended for reading about how to design interfaces.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
When coding, what in your experience is a better approach?
Break the problem down into small enough pieces and then implement each piece.
Break the problem down, but then implement using a top-down approach.
Any other?
I tend to design top-down and implement bottom-up.
For implementation, building the smallest functional pieces and assembling them into the higher-level structures seems to be what works best for me. But, for design, I need to start from the overall picture and break it down to determine what those pieces will be.
Here's what I do:
Understand the domain first. Understand the problem to be solved. Make sure you and the customer (even if that customer is you!) are on the same page as to what problem is to be solved.
Then a high level solution is proposed to the problem and from that, the design will turn into bubbles or bullets on a page or whatever, but the point is that it will shake out into components that can be designed.
At that point, I write tests for the yet-to-be written classes and then flesh out the classes to pass those tests.
I use a test-first approach and build working, tested components. That is what works for me. When the component interfaces are known and the 'rules' are known for how they talk to each other and provide services to each other, then it becomes generally a straightforward 'hook everything together' exercise.
That's how I do it, and it has worked well for me.
You might want to look over the Agile Manifesto. Top down and bottom up are predicated on Built It All At Once design and construction.
The "Working software over comprehensive documentation" means the first thing you build is the smallest useful thing you can get running. Top? Bottom? Neither.
When I was younger, I worked on projects that were -- by contract -- strictly top down. This doesn't work. Indeed, it can't work. You get mountains of redundant design and code as a result. It was not a sound approach when applied mindlessly.
What I've noticed is that the Agile approach -- small pieces that work -- tends to break the problem down to parts that can be grasped all at once. The top-down/bottom-up no longer matters as much. Indeed, it may not matter at all.
Which leads do: "How do you decompose for Agile development?" The trick is to avoid creating A Big Thing that you must then decompose. If you analyze a problem, you find actors trying to accomplish use cases and failing because they don't have all the information, or they don't have it in time, or they can't execute their decisions, or something like that.
Often, these aren't Big Things that need decomposition. When they are, you need to work through the problem in the Goals Backward direction. From Goals to things that enable you to make that goal to things that enable the enablers, etc. Since goals are often Big Things, this tends to be Top Down -- from general business goal to detailed business process and step.
At some point, we overview these various steps that lead to the goals. We've done the analysis part (breaking things down). Now comes the synthesis part: we reassemble what we have into things we can actually build. Synthesis is Bottom Up. However, let's not get carried away. We have several points of view, each of which is different.
We have a model. This is often built from details into a larger conceptual model. Then, sometimes decomposed again into a model normalized for OLTP. Or decomposed into a star schema normalized for OLAP. Then we work back up to create a ORM mapping from the normalized model. Up - Down - Up.
We have processing. This is often built from summaries of the business processes down into details of processing steps. Then software is designed around the steps. Then the software is broken into classes and methods. Down - Up - Down.
[Digression. With enlightened users, this decomposition defines new job titles and ways of working. With unenlightened users, the old jobs stay and we write mountains of documentation to map old jobs onto new software.]
We have components. We often look at the pieces, look at what we know about available components, and do a kind of matching. This is the randomest process; it's akin to the way crystals form -- there are centers of nucleation and the design kind of solidifies around those centers. Web Services. Database. Transaction Management. Performance. Volume. Different features that somehow help us pick components that implement some or all of our solution. Often feels bottom-up (from feature to product), but sometimes top-down ("I'm holding a hammer, call everything a nail" == use the RDBMS for everything.)
Eventually we have to code. This is bottom up. Kind of. You have to define a package structure. You have to define classes as a whole. That part was top down. You have to write methods within the classes. I often do this bottom-up -- rough out the method, write a unit test, finish the method. Rough out the next method, write a unit test, finish the method.
The driving principle is Agile -- build something that works. The details are all over the map -- up, down, front, back, data, process, actor, subject area, business value.
Yes. Do all of those things.
It may seem sarcastic (sorry, I revert to form), but this really is a case where there is no right answer.
Also in the agile way, write your test(s) first!
Then all software is a continual cycle of
Red - the code fails the test
Green - the code passes the test
Refactor - code improvements that are intention-preserving.
defects, new features, changes. It all follows the same pattern.
Your 2nd option is a reasonable way to go. If you break the problem down into understandable chunks, the top down approach will reveal any major design flaws before you implement all the little details. You can write stubs for lower level functionality to keep everything hanging together.
I think there's more to consider than top- verses bottom-down design. You obviously need to break the design up into manageable units of work but you also need to consider prioritisation etc. And in an iterative development project, you will often redefine the problem for the next iteration once you've delivered the solution for the previous one.
When designing, I like to do middle-out. I like to model the domain, then design out the classes, move to the database and UI from there. If there are specific features that are UI-based or database-based, I may design those up front as well.
When coding, I generally like to do bottom-up (database first, then business entities, then UI) if at all possible. I find it is a lot easier to keep things straight with this method.
I believe that with good software designers (and in my opinion all software developers should also be software designers at some level), the magic is in being able to do top-down and bottom-up simultaneously.
What I was "schooled" to do by my mentors is start by very brief top-down to understand the entities involved, then move to bottom-up to figure out the basic elements I want to create, then to back up and see how I can go one level down, knowing what I know about the results of my bottom up, and so forth until "they meet in the middle".
Hope that helps.
Outside-in design.
You start with what you're trying to achieve at the top end, and you know what you've got to work with at the bottom end. Keep working both ends until they meet in the middle.
I sort of agree with all of the people saying "neither", but everyone falls somewhere on the spectrum.
I'm more of a top-down kind of guy. I pick one high level feature/point/whatever and implement it as a complete program. This lets me sketch out a basic plan and structure within the confines of the problem domain.
Then I start with another feature and refactor out everything from the original that can be used by the second into new, shared entities. Lather, rinse, repeat until application is complete.
However, I know a lot of people who are bottom up guys, who hear a problem and start thinking about all the support subsystems that they could need to build the application on top of it.
I don't believe either approach is wrong or right. They both can achieve results. I even try and find bottom up guys to work with, as we can attack the problem from two different perspectives.
Both are valid approaches. Sometimes one just "feels" more natural than the other. However, there is one big problem: some mainstream languages and especially their frameworks and libraries really heavily on IDE support, such as syntax highlighting, background type checking, background compilation, intelligent code completion, IntelliSense and so on.
However, this doesn't work with top-down coding! In top-down coding, you constantly use variables, fields, constants, functions, procedures, methods, classes, modules, traits, mixins, aspects, packages and types that you haven't implemented yet! So, the IDE will constantly yell at you because of compile errors, there will be red squiggly lines everywhere, you will get no code completion and so on. So, the IDE pretty much prohibits you from doing top-down coding.
I do a variant of top-down. I tend to try and do the interface first - I then use that as my list of features. What's good about this version is, it still works with IDE that would otherwise complain. Just comment out the one function call to what's not yet been implemented.
I'm looking for patterns that concern coding parts of a GUI. Not as global as MVC, that I'm quite familiar with, but patterns and good ideas and best practices concerning single controls and inputs.
Let say I want to make a control that display some objects that may overlap. Now if I click on an object, I need to find out what to do (Just finding the object I can do in several ways, such as an quad-tree and Z-order, thats not the problem). And also I might hold down a modifier key, or some object is active from the beginning, making the selection or whatever a bit more complicated. Should I have an object instance representing a screen object, handle the user-action when clicked, or a master class. etc.. What kind of patterns or solutions are there for problems like this?
I think to be honest you a better just boning up on your standard design patterns and applying them to the individual problems that you face in developing your UI.
While there are common UI "themes" (such as dealing with modifier keys) the actual implementation may vary widely.
I have O'Reilly's Head First Design Patterns and The Poster, which I have found invaluable!
Shameless Plug : These links are using my associates ID.
Object-Oriented Design and Patterns by Cay Horstmann has a chapter entitled "Patterns and GUI Programming". In that chapter, Horstmann touches on the following patterns:
Observer Layout Managers and the
Strategy Pattern Components,
Containers, and the Composite Pattern
Scroll Bars and the Decorator Pattern
I don't think the that benefit of design patterns come from trying to find a design pattern to fit a problem. You can however use some heuristics to help clean up your design in this quite a bit, like keeping the UI as decoupled as possible from the rest of the objects in your system.
There is a pattern that might help out in this case, the Observer Pattern.
I know you said not as global as MVC, but there are some variations on MVC - specifically HMVC and PAC - which I think can answer questions such as the ones you pose.
Other than that, try to write new code "in the spirit" of existing patterns even if you don't apply them directly.
perhaps you're looking for something like the 'MouseTrap' which I saw in some articles on codeproject (search for UI Platform)?
I also found this series very useful http://codebetter.com/jeremymiller/2007/07/26/the-build-your-own-cab-series-table-of-contents/ where you might have a look at embedded controllers etc.
Micha.
You are looking at a professional application programming. I searched for tips and tricks a long time, without success. Unfortunately you will not find anything useful, it is a complicated topic and only with many years of experience you will be able to understand how to write efficiently an application. For example, almost every program opens a file, extracts information, shows it in different forms, allow processing, saving, ... but nobody explains exactly what the good strategy is and so on. Further, if you are writing a big application, you need to look at some strategies to reduce your compilation time (otherwise you will wait hours at every compilation). Impls idioms in C++ help you for example. And then there is a lot more. For this reason software developers are well paid and there are so many jobs :-)