First off I apologize for the slightly vague question.
I'm a self-taught coder and the more I work, the more I find myself wanting to invest in the whole process (and God knows there is room for improvement).
I'm looking for very "basic" material (books recommendation if you can!) about things like how to structure code and comments to make things clear, how to structure a project directory (How far should I divide my stuff into packages? How to properly name classes, subclasses, make it all understandable and clear?), this kind of stuff. Not the actual how make things work, but rather how to make things clean, understandable and well structured.
I've been reading a lot on design patterns, good software design and things like that, but there is this "gap" in my knowledge where I can think of a good solution to my problems, but the execution itself is pretty messy and ugly.
I've always worked solo, and chances are I will soon be working with other coders on my projects. Right now I sometimes have trouble understanding my own code, so there is no way others could dive in and help me.
I'm coding in AS 3.0, should anyone wonder.
Thank you very much :)
Depending on how new you are to coding, I'd recommend looking into why 'encapsulation' makes sense.
When I was new to object oriented programming I couldn't understand the appeal of encapsulation, but now I see how it really can help keep your code 'clean' - and I strongly suspect it's fundamental to a lot of other object oriented concepts; Design patterns, avoiding 'tight coupling', composition, code reuse and so on.
Here's the wiki info on encapsulation...
http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)
..but here's my summary:
I've heard the analogy of a car used: The user doesn't need to know HOW the engine works; they just need to know that, when they turn the key, the engine WORKS. Encapsulation keeps the implementation of a class's methods secret. The methods themselves are public (to be accessible outside the class) but properties are private.
By making properties private and limiting the number of public-facing methods in your classes you can have your classes operate as independently as possible. It also means you can totally change HOW a method is implemented inside a class (so long as it retains the same name and argument signature) without anyone OUTSIDE of that class needing to know anything about it. Even if that 'anyone' is YOU it can still really speed up development because you're not having to track down multiple references to public variables of the class throughout your code.
So AIM to have your classes perform one function; Think about if a method would, in fact, be better 'hidden away' in another class. Even if you have multiple objects instantiated 'inside' another, your code will be much more clean and you can be more sure about WHERE that specific piece of code you're searching for is - if a class mostly has one function, it's easier to remember what it does.
Other than that, I'd also recommend using only shallow inheritance; Having a complex hierarchy of classes and subclasses can lead to objects that need to inherit from more than one class. Look into 'composition' and interfaces too. (Interfaces are kind of AS3's solution to not having multiple inheritance).
Related
I've been working on the web for quite a long time and I saw the "best practices" evolve. I'm now fairly convinced separating HTML (Content), Javascript (Behavior) and CSS (UI) is the best thing to do.
A few months ago, I started using knockout.js . I did choose it among other similar frameworks like backbone or angular because a chapter in an MVC training I followed was about knockout, and the concept seduced me. Then after a quick comparison on the web it didn't look as a bad choice for my needs, and for a start.
But here's my problem : when I look at my HTML code now, after a few weeks of dev on a project, there's quite a lot of knockout bindings in it, and it makes me think a lot about the old times, when we (or at least I) used to put inline javascript event handling through onclick attribute and so on.
Therefore those 2 questions, which I'm not sure are 100% suited for SO, but I can't find any better StackExchange site to ask it :
Is using knockout (or the other frameworks as they all seem to basically work with the same pattern) contrary to the "separation rule" ? Or is it an acceptable small-step-out of this rule ? or is it even perfectly acceptable because it uses the "data-" attributes ?
In the case this would be a somehow bad practice, is there any possibility to do all the binding through a separate javascript file, using for example jQuery to select the controls and apply bindings to them ? If not possible in knockout, is it with another framework ? I must admit at the time I did my selection, I diddn't think about this kind of implications...
Thank you and sorry if this should be moved to another SE site.
I had the same initial reservations as you, but I have to say that having the bindings in the html and not hidden away in a JS file seems so much better to me, as the link between presentation and functionality is now completely obvious. It massively reduces the possibility of changing some HTML and breaking functionality because you weren't aware that someone had hooked up some javascript to an element using jQuery.
Also, as you point out, the use of the data-bind attribute does, I think, mean that it does adhere to the separation rule, though if you want to stick to it rigidly then make sure all bindings are to observables, computed or functions on your view model, don't use any code (i.e. a visible binding that checks the state of two observables). I'm not sure I'd take it that far though.
I guess everyone started to learn KnockoutJS have the same concerns.
IMHO, there must be some way that connects models(JS object) with views(HTML markup). Then we should have something that says:"When that button is clicked call this function with that arguments." or "Hide this element while you that JS array is empty" and so on. So how we can put/say/state that connection in a readable, reusable and clean way.
If you used another JS file to handle that connection, then you 'll have large lines of code just to put your connection logic and you need to know how to select the DOM element you are targeting. You 'll end up with massive code(probably lot of jQuery) just to make your HTML dynamic and alive(i bet most developers got into that many times). I haven't use other libraries or frameworks but i think they just make your massive code more organized.
On the other hand by KnockoutJS use Declarative Bindings, this is the link between models and views. It's more readable, easy to plug it in/out and it allow you to just focus on writing a good JS model object.
I guess to truly check separation think what if you sometime needed to change your model, how much changes you need to do to your view? and vice versa?
Adding to the rest of the answers, some tips:
Make sure there's no business logic in your bindings. Any logic (which should be minimal) should be "view logic": decisions that only affect how your view looks, not how it works. Deciding how many items to display per screen is view logic; deciding whether the user can add another item is business logic. It's perfectly OK to put view logic in your viewmodel rather than your view, and it's desirable if it involves lengthy expressions.
Keep "magic numbers" out of any view logic in your bindings. If it's a parameter that could be changed (e.g. number of weeks of results to show) as opposed to a true constant (e.g. number of days in a week), make it a property of your viewmodel and reference it in any expressions in your views.
I'm working on a project in Flash CS4/AS3 and I have a document class set up but I am wondering about using that, as opposed to frame-based scripting. Most of what I have seen so far deals with how to create them, but doesn't offer much about why or when to use them.
I know I can also pull in other classes beyond the document class but, again, why and when?
Could I get some input from you fine people out there on usage/best practice, etc?
Thanks
If this is just a simple demo or a movie, you can use the time line.
But if you're going to make a program, with classes, you should have a document class.
A document class is the main class of your programs. it's actually your initializer of all the program's processes and components, and it's simply more proper and similar to other programming languages.
Plus, it's in a different file, and it is easier to edit it this way.
Also, your doc-class will be a class and not just code in the air.. it also has auto-complete in CS5.
I believe, I program good, at least my code produces results...
But I feel I have drawback... I hardly follow any naming conventions... neither for variables.. nor for methods... nor for classes... nor for tables, columns, SPs... Further to this, I hardly comment anything while programming...
I always think that, Let me first see the results and then I will come and correct the var names and other things later... (Thanks to visual studio's reflection here)... But the later does not come...
So, I need tips, to force myself to adopt to the practice of following naming conventions, and commenting...
Edit : I totally understand the ill effects of my practice, and I also know, that it is bad... My question is how do I force myself to follow the discipline...
Are you able to ask others for code reviews? Or even try pair programming? Both of those can really help you to do things you know you really should do.
Also, depending on your language/platform, there may well be lint-like tools you can run to check your code's health.
I hope you get to spend a few years working on code produced by someone else that has the same poor coding practices that you have. Only then will you truly understand how poor your code really is. Code that "works" is the bare minimum, writing code so that it is easy to to support, extend and maintain is where the genius of a good programmer is.
My gut tells me that your code is probably not as good as you think if you have no standards. You really just have to pick something, and stick to it. Being haphazard in coding style probably means you are haphazard in logic, which probably means you have a lot of bugs, and unexpected results in your code that will be hard to deduce later. Good luck.
Just remember the general coding guidelines you need to follow. And as you write the code write as per the guidelines with proper variable naming conventions for variables and methods and have function headers. Dont think whether your code will work or not, and code as per the guidelines.
Comments can be added later, but the naming conventions has to be followed even while doing a proof of concept.
Write your code with a confidence that its going to work.
Have your code reviewed by your peers, and also you can use Fxcop for static code findings.
Best of all, your code should work and should do what it's supposed to. It's what you get paid for.
However, if it is not readable, then it will fade into existence, because in time you will not remember what it does. To avoid this, refactor and document your code as soon as it works. As a rule of thumb, you should not be satisfied with your work before it is documented properly. For each method you write, this should not take too much time. But the longer you wait, the more time it will consume to figure out what your code was supposed to be doing.
I know the best way of all is to document before writing, but that won't work with cowboy coders. The other way around might be a good alternative, because readable and good documented code shows off a developer's skills.
This is a matter of coding discipline. If you want to prototype something and then throw the code away, this is acceptable. However, the instant you need to reuse or debug your code, you will regret having no comments and poor method/variable name choices.
While you are working with the code now, you know what it is doing. In a few months to a year, you will not remember everything so clearly. Then, you will likely regret not commenting your code and not choosing good names.
Consider, too, if someone else were to read your code, how easy would it be to understand?
Running something like StyleCop (if you're writing C#) can go some way towards this. It won't warn you about everything, but you can use it to make sure your methods have documentation comments etc.
However, as others have said coding discipline is something that has to come from within, not without.
If you want to change something about yourself, you need to motivate yourself to change it. That's one of the "rules of life."
This isn't really something Stack Overflow can help you with. I suppose that a good suggestion to build up some motivation is finding yourself a job as a developer and see how far your development habits lead you...
-Carlos Nunez
I am kinda new to AS 3 development.. and the thing is I am always getting into problems how to structure the different views of an application state?
Do you use a MVC framework for this? I have looked at some puremvc, robotlegs but our flash projects are usually relativly small so I wonder if it is not a overkill :)
Design patters are good as long as you don't try to use them for the sake of using them. I always have my views separate to model as it is, but rarely work on something big enough to warrant a flow blown implementation of something like PureMVC. On large projects then yes they can be beneficial. The hard part is deciding how "big" is big enough to use them. Probably comes down to experience to make that judgment.
Anyway just make sure objects are loosely coupled and that your model and view are not one and the same. Quite often instead of extending a MovieClip I prefer to use composition and have a class have a MovieClip. For me I think it helps separate visuals from the data.
To be honest I'm not a fan of applying traditional design patterns to Flash development. If you're writing pure classes then you can do anything you like, but if you're linking classes to visual elements (like MovieClips), I find that the proper way to structure things (i.e. the way that best avoids duplication of effort and preserves separation of concerns) winds up being dictated by how you need to stack and/or nest your display timelines.
In other words, I find it better to work out at the display level what things ultimately will need to be in the same or in different timelines, and what will ultimately need to be nested or not nested, and then work out which classes should extend or compose each other afterwards.
But note that this is all assuming you're making stuff where the logic is closely coupled with the display elements, which is what I consider the area where Flash shines. Naturally if you're making a loan simulator with no animations or skinning or whatever, it's sensible enough to just use an MVC pattern and then slap a static display layer on top, with each button pointed to a C and each text box pointed to a V. But then that's exactly what you'd do if you were making the same thing in Java, or as a JS-powered HTML form, or whatever else. The advice in this answer is what I find works best when you're making the sorts of heavily visual things that would be ill-advised to attempt in anything but Flash.
A framework can be particularly valuable if you intend on handing the code off to someone else. Whatever framework you choose, you'll introduce a common set of expected relationships from which someone can build an understanding of the codebase.
If the view logic is largely sequential, or at least modal, an easy non-framework mode of organization is to group your views into "pages" and have a single controller manage which page is on-stage at a time and feed in model data from wherever.
if you are really new to AS3 and are planning to do "pure" coding (neither using the graphical approach promoted by the Flash authoring tool, nor diving into the Flex world), i suggest you don't waste your time on AS3 and move on to Haxe ...
Haxe is not very well known, so the only opinions you'll get are from people using it ... there's a little bias of course, but you may read their statements here, here and here ...
now when it comes to patterns and framworks, there are many possibilities ... design patterns are solutions to a set of problems ... do not make the mistake of trying to transform all the problems you encounter into problems that fit the patterns you know ...
in my book, there is one fundamental principle for software design: DRY & KISS - I admittedly still have a lot to work on the latter ... :) ... for more concrete and guiding principles, I stick to SOLID and GRASP ... if your read them carefully and reflect upon the (good) patterns you know, you are likely to find out, that they incorporate said principles ... do not overuse patterns ... do not overuse any tools in fact ... use whatever tool is the best for the job ...
IMHO, pure AS3 is for geeks ... and I love doing pure AS3 ... or at least I did ... it is however uneffective and unrewarding over time ... it is good for developping frameworks and libraries ... but nor for apps ... Haxe is good for distributed cross-plattform apps (and for geeks), Flash Authoring approach for "fancy" visual apps, and Flex for classic apps featuring prevalant UI concepts ...
While designing my site I am constantly faced with the issue of whether its ok to TAKE ideas and designs from other sites. In some cases there is no distinction in certain aspects. Is there anything ethically wrong with this? Is this expected in the design programming community?
Depends on how much you 'steal'.
Code
If you're ripping off the whole design, then its a bit dodgy. If you like (for example) the Stack Overflow concept of voting up stuff, then steal the concept and use it in a different manner. If you want to know how say the orange highlighting of the up-voted items works, then look at the code. But don't do both and steal both the concept and the design, you'll just create a clone.
Due to the way different web browsers treat CSS and the like, there are often only a very few limited ways to do a particular thing (3-column layouts, etc.). It seems fair enough to blatantly copy in these cases where there is a common way of doing things. Where its something unique, and there's many ways of doing it, it seems a bit more off to blatantly copy.
Graphics
Ripping off graphics - not so okay. Images have been around a lot longer than code so copyright law, etc. probably suits them better. If nothing else you have to contend with possible watermarks or other metadata to identify the original source. It's very easy to check for image stealing, less so for code within a larger block.
I'm a coder, not a designer so what I tend to do is borrow graphics that I like just while mocking up my web-app for internal use. Does that seem fair? I'll change them for newly-designed or paid-for ones before going live. At least that's the idea, though it could be far too easy to forget and use them by accident.
That's the way it works in the newspaper world (well it used to, not sure now with the advent of this there Internet thang): You download as many graphics as you can bother waiting to come over your 57.6k modem; you only pay for the ones you actually publish.
Oh, this is a hard question.
On the one hand stealing is wrong, on the other hand you are obliged to save you employer money by solving a task quickly.
My only advice is:
If it feels wrong in your gut, you probably stole too much.
I think most designers and developers draw a distinction between 'creative inspiration' derived from someone else's work and blatant plagiarism.
I wouldn't think twice about peeking under the hood to see how someone had done a particularly nifty javascript effect, or implemented a tricky piece of css elegantly, but I'd find it distasteful to blatantly cut and paste that same code for use in my own development.
I'm not learning anything by just grabbing and reusing - although I think it's fairly standard to have the same code to hand as a rough scaffold from which to explore my own way of implementation. I think that's the way a lot of people work.
I am a web developer, not a designer. As such, I have a sense of taste, but not the ability to come up with something wholly on my own. As a matter of ethics, everything commercial or with the expectation of serious traffic that I do, I will hire a designer. They need to eat too, and there is something wrong with making money off of others work and not compensating them for it.
If it is small, personal, or an internal throwaway type thing, I will rip off things like color scheme and/or layout. Technically you could say this is stealing, but I think of it more as "imitation being the sincerest form of flattery" thing. I don't feel that bad about it since there isn't really any money to be made in it.
I think its ok to steal ideas, but not to steal code.
This is how a lot of design is accomplished. Except it's obscured by lots of lifts, not a single wholesale lift.
Stealing resources (graphics, code) is not really OK if they're not specifically marked as free/open/creative-commons/etc. Stealing design and layout is a bit sketchy if you're just xeroxing the same layout using your own code -- using someone else's design as a starting point is one thing, but don't just recreate their design verbatim. Stealing snippets of code for specific bits of functionality is fine (IMHO) since even if you grabbed a reference manual to learn it from scratch you'd end up with the same thing. (Think: javascript for changing an button image on mouse-hover)
Having said all that, imitation is the sincerest form of flattery. Don't steal resources, but using other sites as "influence" should be OK. Or, if in doubt, ask the owner of the site you intend to use as reference/influence.
It's almost like everyone answering this question forgot what it was like to work with web pages between 1995 and 2002 or so. Stealing was a way of life for tons of designers during that period. The key was, and still is, to take only what you need, and to make sure that you understand it well enough to make it from scratch the next time. Who knows, you might improve something in the process.
There's an old saying I was once told: Good designers create. Great designers steal.
That said however, you should never blatantly rip off code if you can avoid it. Look at it, understand it, rewrite it (or improve it, if possible; even if it's only something like using what you find are better variable names) but never just copy and paste. Same goes for layouts; take the layout and modify it to suit your needs - it might end up looking similar (look at all of the Basecamp-style clones out there as far as UI goes) and that's no big deal at all; plenty of sites look similar. The key is to go into the situation looking for inspiration and not some code to yoink. If you can use the code as-is or with little modification then you really have no problems, but it shouldn't be your intention to find someone else's code and rip it off.
It's a sliding scale. Borrowing just an idea is one thing, if you're incorporating it into the rest of your existing design, not just wholesale copying an idea. Snagging a idea for a design element is fine, copying a whole design exactly is not. As you borrow more and more of a design, it gets into the not acceptable category. Copying directly is also another factor. If you see something you like and reimplement it for yourself, that is typically fine. But doing a direct copy of code, images, or css not so much.
For the most part, ideas are fine to take and implement. If people couldn't take existing ideas and expand them or re-implement them, we'd never have gotten out of the dark ages.
If you feel the need to steal code because you can't code HTML/CSS well or don't have an eye for design, steal from a place that explicitly permits you to use their design/code, like OSWD. In general, stealing HTML is fine, but ripping off CSS wholesale is a no-no. Just because you can easily view the CSS source doesn't mean that it's ok to just copy and paste it.
Don't steal graphics, period. Especially things like photos and logos and icons. If you need that sort of thing, purchase stock photography or take your own photos.
When in doubt, ask the owner of the site.
Stealing code or designs is immoral and in some cases illegal.
Taking inspiration or copying functionality is less of a problem. For example, at some point in time someone realized that putting a "Forgot Password?" link next to all login forms is a good idea, now everyone does it. It's not theft it's just replicating a good idea.
I'm not a web developer, but I might have some insight that will help as well. My team has created several applications that have served as the starting point for other applications delivered to various customers.
The successful derivatives were those in which the developers took the time to learn the architecture and why things were the way they were. They then took the more crusty parts and rewrote them and in general expanded and improved the architecture.
Invariably, when a team simply took the existing project and tried to 'brand it' or copy it for a customer without actually figuring out the systems, they either created poor implementations of the extensions or had the project fail outright.
I realize this is a bit off the main topic of the ethical issues address by others here just fine, but my bottom line is that pure theft usually costs you more time than it saves.