Related
When I write html and css, does it matter if I do things "my way", like using an abundance of absolute positioning, or maybe coming up with very unorthodox solutions to certain problems like layout? Since I'm not great right at markup right now, I am kind of just "doing what works." I'm reading as much as I can but I know I am making mistakes. Is it important that I pay extra special attention to exactly how I'm writing it so I don't develop bad habits, or should I just be happy that it validates and that is the most important thing?
It has to do more than validate. It has to look good, or at least be functional. The only way to truly validate that is via extensive testing.
It's worth noting that the standard patterns are there for a reason—because they work. But they're certainly not gospel. Metaphorically speaking, there's more than one way to skin a cat. There's no reason for too much hand-wringing if you find alternative solutions that work for you. The only real concern is that your code might be more difficult to understand and/or maintain in the future, either by you or by someone else.
Above all, though, the best way to learn and improve is to practice. And there's no better way to practice and discover your mistakes by writing and shipping actual code. If you make a mistake, chalk it up to experience. That's what we all do.
I'd say it's somewhere in the middle. It's important to always ask yourself "is this the best way to write this", but it's equally important to not get too hung up worrying about the perfect way to do things and just ship code. The more experience you get by getting stuff out there on the web in people's hands, the better position you'll be in to know what "the best way to do things" is.
It will all start to matter once other user has to maintain your code.
You should watch these videos. http://code.google.com/edu/submissions/html-css-javascript/
"should I just be happy that it validates" I would say never. If your code is working well doesn't mean that it is setting upto the mark.And the best way of knowing you have done correct coding or not is check your HTML pages in all the available browsers/in different OS with different screen resolutions etc. You may like to see what are the standards defined (however may vary depending upon your application needs) for CSS and HTML. So try to learn those things instead of doing it in "your way". Here is one reference for you.
Standards HTML/CSS
I am starting server side programming with RoR. I am noticing that it's tightly coupled with css/html web design. (Maybe I am just perceiving it that way since this is my first time doing server side stuff).
I just want to know, are server side programmers usually well knowledgeable in css/html layout stuff? I understand the ruby part, but css is giving me a headache. Debugging with different browsers/testing/ a lot of trial and error and still buggy. Finally you get it to work with Firefox and I.E doesn't work anymore...
How do server-side programmers out there usually tackle the "looks"/UI? Do they get someone else to do the css stuff and worry mostly about the functionality?
Thanks.
I answered a similar question here.
Most of the times from something basic, like twitter-bootstrap is now fantastic to get something up and running quickly.
What happens next is up to you: either you have some interest and learn some design skills. Or you get in touch with a designer to do the designing for you. I seriously think you will need to have some HTML/CSS skills yourself, but that is not the same as designing.
It depends on the development shop your working for I suppose. Larger companies tend to have some people focus on the backend, and some on the front end to best suit peoples talents.
I would highly recommend becoming familiar with the front end UI as well for your own benefit though. Most small web development shops are seeking full stack developers that can manage all aspects of the web app from server configuration, backend logic, and UI. You'll be much more well rounded in solving your own challenges, and become a more valuable employee with a diverse skill set.
Since your using RoR I would recommend becoming familiar with SASS and Coffescript since they can save a lot of development time. Also sass provides excellent mixin features to help solve your CSS cross browser issues, which you can find several prepackaged ones in Thoughtbots bourbon gem. https://github.com/thoughtbot/bourbon
The question is impossible to answer.
Many server-side devs are well-versed in HTML, CSS, and JavaScript, at least up to the "Oh that's the IE7 off-by-one bounding rectangle absolute-div positioning bug" point.
However, I think some groups of server-side devs are generally more adept than others: server-side environments like RoR, PHP, and so on tend to push more HTML/CSS onto the devs than, say, Java.
For me, the trick has been to keep the HTML and CSS relatively clean (sass/scss helps a lot), not obsess about pixel-perfect cross-browser appearances, and have layouts that you don't have to mess with much. There are HTML/CSS frameworks that help in this regard.
Conversely, a lot of designers don't know enough JavaScript to be useful--I think it is important for site developers to know enough JavaScript to provide the necessary functionality. Here again, the frameworks tend to breed different levels of JavaScript awareness, although that's changed somewhat as more sites get more interactive.
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
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.
Whilst working on some generally horrible Javascript code this morning, I came across the following (in multiple places):
// make moveAmount negative
moveAmount = moveAmount - (moveAmount * 2);
I sit directly across from the guy that wrote this; he's been a developer here for seven years. I, on the other hand have just started, am pretty junior and don't claim to know jack.
Nevertheless it has got me wondering about the guy's contortions of simple logic after so many years developing software.
My question is what view others here might take of the overall competancy of a developer that wrote this (3 weeks ago), or does it even reflect at all?
Would anyone point out the convolution?
I, myself, work in constant dread that such judgements be made of me.
Simple solution: Show him the line of code and ask why he did it. It's an opportunity for both of you to learn something. Maybe there was a bug in a browser or some other issue (rounding comes to mind) so the code might break without this. Or he made a mistake. Either way, asking will clear this up.
And while you're right that other people will judge you from the code they see from you, that is not the only thing they take into consideration (and if it is, then you're working at the wrong place -- leave while you're still sane). They will also see when you're polite, curious, helpful.
These things count more than the code you write: Code can be fixed much more easily than angry co-workers.
Your example may be poor code, but I've seen worse (after all, there are circumstances where it will work; some code can't even say that). I think the question you're really asking is: is there any line of code so awful that it means the developer can be deemed incompetent on the basis of that one line?
I say no. I have two children who were terrible sleepers as babies. I've come to work with the flu. I've been at work in death-march mode where I've been working twenty hours in a row. In such circumstances anyone can write a terrible line of code. (This is why such circumstances should be avoided.)
Granted, I would hope I would spot the dreadful code later, and fix it.
Well it works so you would just look like a p**** if you told him that you dislike that code and probably rightly so :) Then again he might have done that code 7 years ago as the very first JavaScript he wrote, but seriously never judge someone from just ONE LINE of code.
Regarding the fear of judgement, relax. It's true, we're all going to be judged by someone at some point, whether it's some pointy-haired boss or maleveolent little upstart. The main thing to get to grips with, I think, is how to get something useful out of every such encounter.
Obviously, there are going to be people griping about things for the sake of it, but you'll also find many similar situations where there's something to be learned.
The suggestion above to start a dialogue with your co-worker is excellent; it may directly feed into just such an encounter, from which either, or both of you, may learn something important.
It's tempting to find one example and generalize about a developer, but unless he has a track record of this sort of nonsense, I would consider it an isolated incident. Simply ask him why he didn't write :
moveAmount = moveAmount * (-1)
this behavior is different from
mountAmount = -moveAmount in the case where 2*moveAmount may cause an overflow if moveAmount was big enough (like 2^32-1 for example).
I don't know if that was his intention though.
Since he wrote it 3 weeks ago, I would say he should be open to criticism for this line. It shows an immaturity that is really inexcusable after 7 years of working professionally.
If he would have at least done this:
moveAmount -= moveAmount * 2;
He would have gotten less flack. It at least shows that he's aware of the other operators and is making some effort to make things more readable.
I don't think that you can always judge people with one line, but the code can tell you so much about a person's aptitude that one line can tell a lot about a person.
I say it will depend on the swallow. If isolated, the line of code you've shown is something I would expect from an exhausted programmer, even if a very competent one. It is an example of something just not very clever and tired people do not so clever things. If, on the other hand that kind of code appears frequently then probably you're working with someone with a twisted mind.
Things that are obvious indications of a bad programmer are related to bad practices. Good programmers will not make huge methods. Even tired, they will try to keep their types loosely coupled. They will avoid exposing public fields instead of exposing them through accessors or properties. They will try inheritance and aggregation as forms of code reuse rather than repeatedly doing copy-paste... The list is long. Those are the kinds of swallows that lead me to almost instantly feel it is summer. :-)
If he wrote that when he was first beginning, he gets a pass. If he wrote that recently, he gets a thumbs down from me. The overall competency of the developer is definitely suspect.
Others are saying you can't judge a developer by one line of code, but I say it can certainly cast doubt upon his competence. I'm not suggesting you jump to conclusions, but that type of code is certainly evidence of a mediocre developer at best.
... and as for it being related to being overtired or stressed or whatever... the bottom line is that code quality is important. If he wrote a one-liner like this, what else may have been written that doesn't stand out so easily?