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
It seems like whenever I use the Command Pattern, it always leads to a significantly larger number of classes than when I don't use it. This seems pretty natural, given that we're executing chunks of relevant code together in separate classes. It wouldn't bother me as much if I didn't finish with 10 or 12 Command subclasses for what I might consider a small project that would have only used 6 or 7 classes otherwise. Having 19 or so classes for a usual 7 class project seems almost wrong.
Another thing that really bothers me is that testing all of those Command subclasses is a pain. I feel sluggish after I get to the last few commands, as if I'm moving slower and no longer agile.
Does this sound familiar to you? Am I doing it wrong? I just feel that I've lost my agility late in this project, and I really don't know how to continuously implement and test with the speed that I had a few days ago.
Design patterns are general templates for solving problems in a generic way. The tradeoff is exactly what you are seeing. This happens because you need to customize the generic approach. 12 command classes does not seem like a lot to me, though, personally.
With the command pattern, hopefully the commands are simple (just an execute method, right?) and hence easy to test. Also, they should be testable in isolation, i.e. you should be able to test the commands easily with little or no dependencies.
The benefit you should be seeing are two-fold:
1) You should have seen your specific, complicated approach simplified by using the pattern(s) you chose. i.e. something that was getting ugly quickly should now be more elegant.
2) Your should be going faster, due to the simplified approach and the ease of testing your individual components.
Can you make use other patterns, like composite, and use good OO design to avoid duplicating code (if you are duplicating code...)?
That doesn't seem like a lot of command classes, but I agree with you that it smells a little if they make up more than 60% of your classes. If the project is complex enough to merit the use of the command pattern, I suspect you'll find some classes begging to be split up. If not, perhaps the command pattern is overkill.
The other answers here have great suggestions for reducing the complexity of your commands, but I favor simplicity where I can find it (ala the bowling game).
Related
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 2 years ago.
Improve this question
An absolute pet hate are naming rules for the sake of it, when development enviroments are so good at letting users know what each item is.
As the title suggests are there any pitfalls if a developer were to name all types, objects, variables etc.. 'all in "snake_case", specifically in Kotlin. Ignoring the auto generated names for binding etc.
Coding style, such as naming, doesn't matter to the compiler.
But it matters to humans — and as a couple of wise people once said, “programs must be written for people to read, and only incidentally for machines to execute.” (They were probably exaggerating for effect, but I think there's still a grain of truth there.)
Consistency in naming means that you don't have to stop and think about whether to use underscores or capitals (or spaces or dashes or whatever inside backquotes); it makes classes and methods easier to find in your code as well as in libraries and frameworks; it plays better with Kotlin properties (which look for getXxx/setXxx/isXxx method in the bytecode); it removes a source of disagreement among developers; it's less likely to cause problems with IDEs and frameworks and source-code tools which tend to assume you're using standard naming conventions; it makes the codebase easier for new developers to get up to speed with.
But, more than all those, code which doesn't follow conventions iS_нa℞𝐝𝑒𝕽-τଠ𐍂ɘⱭ𐐼. When things that work the same look the same, differences are easier to see. The less time you spend deciphering names, that more time is left for understanding what the code is doing with them. It's the same reason why we use consistent indentation and spacing and structure and design patterns. With fewer surface differences, you can more easily see the underlying structures and patterns in the code, and deviations (and hence bugs) become more obvious.
Coding — by which I include debugging, maintaining, and enhancing as well as writing fresh code — is hard, and we humans are limited, so we should make things as easy for ourselves as possible. Developing software is a constant battle against complexity; every little simplification helps. You may think that using snake_case instead of camelCase is insignificant; but the mere fact you're asking about it here shows that it makes a difference!
The answers to this question and this question give many more (and better-argued) reasons why consistency is important.
(As it happens, I've spent many years using languages which prefer snake_case, and also with those which prefer camelCase, and I definitely find the latter easier to read in context. But that's a much less important consideration than consistency.)
Apart from arguing about that with other developers, and calls to all library functions looking different, the language will work perfectly and not care about that.
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 7 years ago.
Improve this question
This is not a specific question about a certain piece of code and apologies if my current question is not valid on StackOverflow. With Such a big Community I am just curious to find a common approach for best practices.
It's not that I Don't know how to code the OOP way, but while my code keeps growing I am losing track and my code actually bluntly stated gets "ugly". What happens is that it takes a lot of time to rewrite my code to finally have it correct again.
Don't get me wrong. I really take time and dedication to adapt my code the best way I can. I rewrite parts that can be rewritten etc. Actually I want to avoid to rewrite and I know it takes alot of practice. Any Guidelines/Tips regarding taking on a project is highly appreciated.
I Have written Code already in OOP way, but it's small code/project based and now when I am starting to take on bigger projects I lose track.
My question is simply: Am I the only one that has this? And how to keep my coding neat all the way to the end?
Thanks in advance for any tips regarding this situation. I just want to write better and cleaner code.
In practice, you often might need to update your existing code to meet the new requirements. But if this is something you are doing on regular basis, then it is possible that your development process is not good enough.
You may lack a beforehand thinking and planning process.
What do you do when you have a new development task? Do you just go on and write some code?
I use the process like this:
1) User story.
Describe a user story, it often comes from the customer or users. This can be something like "I want to have a new beautiful chart of the recent data on the dashboard".
2) Requirements specification. Start asking questions and add details. You may need to create a separate document just to describe all the details - what data exactly should be shown, should it be line or bar or other kind of chart, where exactly should the chart be placed, etc, etc...
Result - a detailed requirements specification. It should be clear enough so you can give it to other developer, who should be able to continue with following steps without asking the questions.
Check also this article 10 Typical Mistakes in Specs.
3) Implementation details. Think how to implement the requirements, describe the classes structure and objects interaction, think on extensibility and flexibility, plan the unit tests for your code.
The basic idea is that you start writing and re-writing your code even before you actually write the real code.
Imagine how your classes / objects will be used, try to write some tests before actually writing the code.
Here is where SOLID principles, design patterns and UML diagrams can be useful to design your code in a good way.
4) Estimation. If you was good at point (3), it will be trivial to split your implantation into small steps and estimate how much time you will need for every step, like:
Database migration - add new tables - 1h
Implement ClassA, ClassB, ClassC - 1h
Implement ClassD, with a special calculation algorithm - 4h
Unit tests - 2h
Testing, fixing bugs found - 20% of the above
I usually use this scheme of estimation (along with 20% for unexpected things) and it is possible to get very accurate estimations. Like for a 40 hour task it can be 1-2 hours error, it should never be something like 50% error.
5) Implementation. Here you just go on and do the task.
Everything is planned, everything is absolutely clear.
No thinking on design and strategy, only local decisions (like do I use for or while loop here?).
This way you minimize the amount of "surprises" during the implementation and reduce the need in re-writing the code later.
Always keep SOLID in mind. That will help you to stay on the right track. Here is a good start http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
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 3 years ago.
Improve this question
I'm starting project number 8,192. Like most of my projects, they are either throw-away projects or projects that get canceled either from boredom, time or lack of usefulness.
But there is a project that has been on the back-burners for a long time that I really want to finish. In my perfect world mind, it should take 3 months for first release.
Anyway, one of my biggest issues is taking a large project (or even a small to medium one) and break it down into manageable pieces. My error is to always jump right on the terminal, open Textmate and start coding. This almost always fails. I get lost in feature creep, learning newer methods, framework wars, etc. Then, two months have gone by and nothing to show for it.
So I was thinking if BDD (such as Cucumber) might be a solution to this? Could it be used to scope out the larger pieces, then the smaller pieces until I have a feature list that is most of the project. At that point, I just start coding the pieces right?
What are your suggestions on tackling this problem that I'm sure other developers share.
BTW, I'm using Rails 3 (sometimes Padrino).
Thanks
On which track? BDD doesn't define the track--it communicates the track.
BDD may be the only requirements you have (or need), but that doesn't address the issue of feeping creaturisms unless you have the discipline not to implement anything for which no spec exists.
Uncaptured features don't get implemented, period. If a feature is added, it gets a scope, and is prioritized with the rest of the features. It may usurp something less-desirable, it may not.
The product owner (you in this case) must decide how much can be implemented in the time allotted, and which features should be implemented. Still boils down to discipline, however, you just have a tool that (helps) make sure what you implemented is what you actually wanted.
It doesn't, however, make sure that what you get is only what you originally wanted--it won't make sure nothing else is implemented on top of the specs you bothered to implement.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Its my last semester of college and I have to do a big presentation in December. I plan on designing a small language that not only works, but also has some nifty features to go with it. Does anyone have any interesting syntax ideas or features that would impress my professors?
Note: I do not want to just copy a language and reimplement it. Im looking to do a little research and try some new ideas out.
I have a crazy idea.
There are compilers that compile compilers. This is fun enough by itself.
You can implement one in the MetaII style (read this other SO answer:
Are there any "fun" ways to learn about Languages, Grammars, Parsing and Compilers?)
What makes this doable for a student project is that the MetaII compiler is remarkably small, and
the technical paper (read the other answer) has everything you need in 10 pages
except some sweat, which you supply. And this fits
well in the time frame you have available (which is frankly pretty short for as student
to just sit down and whack out a compiler by himself).
MetaII's own description of itself is remarkably terse: only some 50 lines(!).
And since it can compile itself, it can compile enhanced versions of itself... so
you can use it to bootstrap much more complicated compilers. Normally, that's the
direction most people want to take it, since MetaII by itself is fairly simple.
Here's the crazy idea: You can also use it to compile less capable versions of itself.
The question is, how much can you take out, and still be able to climb back up the
metacompiler ladder? How small a compiler can you build that is still bootstrappable?
I know for a fact that MetaII has 2 items are removable, since I've done
this in the long distant past. I'm not going to tell you what they are becuase
that spoils the discovery process. But its good in a student project to take
on something that is already known to be doable, so you don't go down alleys
that have real dead ends.
One of the people I'm knew long ago apparantly tried to do this seriously. His goal was to reduce this to a very short string of characters... think of this as "compiler DNA".
Whilst I might not be able to answer your question directly, I am sure this will give you some insights from my own experience - given, for a final year project I also attempted my own scripting language (in C++) - although I am aware you're attempting a compiler so there might not be similarities. Please learn from my mistakes.
From experience:
What you imagine the scripting language will do (you type in a command, does something nifty like it fixes windows or something) and what it actually does (you type in a command, but minutes later it crashes) can often be two different things. Keep it realistic.
Aside from the brain imagining this fantastic finished product (with no inbetween), it also has a tendency of deluding itself on it's own capabilities (like 'other programmers made that mistake but I won't!'). Chances are you do make the same mistakes, or if not the same, different mistakes.
The brain has a poor ability to assess time required (if it's thinking 'it's just a hack job that'll take a month' - think again), and time it thinks is required should be multiplied between 5 to 10 times (if not more) to get an accurate idea of real scope needed. Keep to the lengthy end of the scope - worse-case scenario.
Unexpected pitfalls. Like 'how do I implement multi-precedented logic statements' and 'it's taking longer than I expected (see 3.)'. Be willing to give up complicated matters.
Design. Don't just look for ideas, think about whether or not it's a viable project, and look at how you're going to implement the groundwork before jumping to the complicated stuff (see 1.). Laying the groundwork early on can save you time. And don't forget design documents.
Research. Chances are that function you plan to write out, has already been written before somewhere. Research for it. This will save you time. Do not reinvent the wheel and do not be concerned about efficiency (university is about learning).
As one commenter said, start simple, get it working, then expand.
Best way to develop useful ideas, is to see what really bothers you about a certain task or certain scripting languages, and build it so you can eliminate or minimise that task. For example, I got annoyed by having to keep downloading files from a website and sorting it manually into specific folders - so I built a program to do that for me.
Don't go general-purpose for such a small project. Find a niche where you would like to be able to program a solution to an everyday problem. Off the top of my head, how about a constraint language for window placement in your X11 window manager of choice?
If you're just looking to have some fun, then you should try and create your own 'esoteric language'. 'Brainf**k' has kinda achieved meme status in the community (If I'm not wrong)
http://en.wikipedia.org/wiki/Esoteric_programming_language
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 4 years ago.
Improve this question
Stackoverflow users,
How do you keep yourself from creating large classes with large bodied methods. When deadlines are tight, you end up trying to hack things together and it ends up being a mess that needs refactoring.
One way is to start with test driven development and that lends itself to good class design as well as SRP (Single Responsibility Principle).
I also see developers double clicking on controls and typing out line after line in the event method that gets fired.
Any suggestions?
I guess it depends on your internal processes as much as anything.
In my company, we practise peer review, and all code that gets comitted must be 'buddied in' by another developer, who you have to explain your code to.
Time constraints are one thing, but if I review code that has heinously long classes, then I won't agree to the check-in.
It's hard to get used to at first, but at the end of the day, it's better for everyone.
Also, having a senior developer who is a champion for good class design, and is willing and able to give examples, helps tremendously.
Finally, we often do a coding 'show and tell' session where we get to show off our work to our peers, it behooves us not to do this with ugly code!
Use a tool like Resharper and the Extract Method command.
Long classes is one bad code smell of many possible.
Remedying overly large classes by creating lots of small ones may create its own problems. New engineers on your project may find it difficult to follow the flow of the code to work out what happens where. One artifact of this problem can be very tall call stacks, execution nesting through many small classes.
Another suggestion is to do only what is asked. Don't play the "What if" game and try to overdesign a solution. This has the "Keep it simple, stupid" idea behind it.
We're a java and maven shop, and one of the...I guess you could say forensic methods we use are the excellent FindBugs, PMD and javancss plugins. All will give warnings about excessive length in a method, and the cyclomatic complexity calculations can be very eye opening.
The single most important step for me to avoid large classes that often violate SRP was to use a simple dependency injection framework. This freed me from thinking too much about how to wire things together. I only use constructor injection to keep the design free from cycles. Tools like Resharper help to initialize fields from constructor arguments. This combination leads to a near zero overhead for creating and wiring up new classes, and implicitly encourages me to structure behavior in much more detail.
This all works best if data is kept separate from behavior, and your language supports constructs like events that can be used to decouple communication that flows in the downward direction of the dependency graph.
use some static code analysis tools in your automated builds and write/configure/use some rules so that for example someone has to write a justification when he/she breaks it..