NaturalBornSkinner: Bad Coders VS. Lazy Coders - NaturalBornSkinner

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Bad Coders VS. Lazy Coders Rate Topic: -----

#1 User is offline   ClubUgly 

  • Post Whore
  • PipPipPipPipPipPipPipPipPipPip
  • View gallery
  • Group: Admin
  • Posts: 3,358
  • Joined: 02-May 05
  • Thanked: 87
  • Gender:Male
  • Location:Michigan
  • Interests:php, html, css and javascript
  • PHPFox Version:2.0.4
  • Country Flag:United States of America (USA)
Kudos: 89
Excellent

Posted 20 December 2009 - 10:03 AM

What’s the difference you ask? A lazy coder MUST be a bad coder! If you’re lazy then you’re not coding to best practices therefore you MUST be a bad coder.

While the above in part is true, there is an integral difference between someone who is a flat out BAD coder and one who is just a bit on the lazy side. If you’re looking to hire a coder there is a few key ways to tell the difference.


How to spot a bad coder vs. lazy coder


  • Tables -Ok people, tables are the WORST possible way you can realize all the hard work someone has put into a design. Are they more often then not cross browser compatible at face value? Eh, yes. But a good coder worth the time and money can translate practically ANY design into a cross browser compatible tableless version of all that hard work.
    • Bad Coder: Will resort to tables immediately. “CSS? That’s for styling my table background and link hovers, right? Right?”
    • Lazy Coder: Will resort to using a small table to contain things such as business hours (that’s close enough to tabular data), or forms.

  • DIVS, DIVS, DIVS and more DIVs! - Take a look at your prospective coder’s HTML. What’s in there?
    • Bad Coder: Is everything <div class="logo">, <div class="paragraph">, <div class="menu1"> etc? Is EVERYTHING controlled by divs? This is bad, bad coding. If the coder knows what they are doing they will be able to control many elements on the page within the CSS by styling just the elements - like, heading tags, lists, paragraph tags, and any available HTML attribute.
    • Lazy Coder: Instead of using the paragraph tag the footer text is wrapped in and defining the styles on that element, a div is added surrounding it.
    Be careful not to judge to harshly as divs ARE a necessary part of coding any design, but if the ids, classes and styles mostly are related to divs, then chances are this particular coder isn’t quite up to par.

  • Unstructured CSS - Take a peek at a coder’s CSS, is it a mess?
    • Bad Coder - Does each section for the sidebar have the SAME look, but the coder has slapped a different class to each portion, and defined each separately in the CSS? Are CSS properties defined separately instead of combined for condensed shorthand? Are there many, many !important, declarations after elements? Chances are high then this coder isn’t a top notch CSS master.
    • Lazy Coder - Do they use a CSS reset method and not redefine more than half of the styles? Or do they use no reset at all? Are there a few too many !important declarations? Chances are this coder is taking the easy way out.

  • No alt="" attribute on img tags
    • Bad Coder - This really doesn’t need too much explaining. If you’re using XHTML images NEED an alt attribute to be defined for it to validate. Don’t care about standards compliancy? You should.
    • Lazy Coder - Generally will miss a few, but even lazy coders are pretty good about remembering a simple alt tag, even if it is just blank (alt="").

  • Images used in HTML where they could have been defined as background-images in the CSS
    • Bad and Lazy Coder - Example: A picture of flowers in a header. If that’s defined as an inline image in the HTML, it’s wrong. Example 2 - Perhaps there is a separator image between articles in your sidebar… this can and SHOULD be easily defined in the CSS as a background image.

  • INLINE STYLES!!!!! - Inline styles have their practical uses and are necessary at times.
    • Bad Coder - That said, if you are seeing repeated inline styles for simple things (like all h2’s in your content area have an inline style of a padding-left:20px) this is bad coding. This easily can be defined in the CSS. The same can be said for embedded stylesheets. The whole point of CSS is to have all your stylistic elements contained in a separate file where you can edit it once and make GLOBAL changes to your website. This is lost if every page has embedded styles when they can be easily put in a CSS file and linked to.
    • Lazy Coder - The lazy coder will sparsely use inline styles. Perhaps on an img that needs to be floated right only a few pages, instead of having a predefined class for that purpose.
    Please be sure not to confuse IE conditional statements with embedded styles (but even these styles can easily be contained in a separate IE targeted stylesheet.

  • Using javascript to control image hover states instead of CSS and text - For something so simple as switching the background on text when hovered over, there is no reason to resort to javascript when CSS can be used alternatively.
    • Bad Coder - Will gratuitously use javascript on things like navigation roll overs, buttons and more, when a few simple lines in the CSS will easily control the same action.
    • Lazy Coder - Even a lazy coder won’t resort to this. They will use CSS to control this, although the lazy coder will be less likely to use the faster loading (also prevents the loading flash on hovers) CSS Sprite method (check out the CSS for the navigation on CSSgirl - an example of using CSS Sprites).
Why is it important to define the differences between these two types of coders? Well, the short of it is - a bad coder is a bad coder plain and simple. Only time and experience will hopefully enhance their abilities. A lazy coder on the other hand is a decent coder in disguise. A lazy coder can easily become a good coder if someone lights the appropriate fire under their behind.


Read more:

0

#2 User is offline   WebmasterX 

  • Member
  • PipPip
  • Group: Members
  • Posts: 18
  • Joined: 16-January 09
  • Thanked: 2
  • Gender:Male
  • PHPFox Version:None
  • Country Flag:United States of America (USA)
Kudos: 8
Neutral

Posted 10 January 2010 - 05:47 PM

Quote

Lazy Coder: Will resort to using a small table to contain things such as business hours (that’s close enough to tabular data), or forms.


Eh, I somewhat disagree, tables should be used, just not for layout, but for displaying of data, I don't see a problem with it, it gives it a more uniform look, business hours actually seems reasonable, other things I'd be apt to use tables for are things like forms, since they give a better look but with that you could do either or. I still say don't throw out tables all together, IMO a bad coder is someone who in all circumstances frowns upon tables; why has coding become so politically correct?

0

#3 User is offline   nrsocial 

  • Newbie
  • Pip
  • Group: Members
  • Posts: 3
  • Joined: 10-January 10
  • Thanked: 1
  • PHPFox Version:2.0.1
  • Country Flag:Canada
Kudos: 5
Neutral

Posted 12 January 2010 - 02:11 AM

What about javascript and server side languages?

Are they up to date with the latest syntax/standards?
Do they format their code and document it well enough with comments?

Those are a couple key things I would look for in hiring people to code for me so I could later customize or edit the code myself. That, and I can't STAND poorly formatted code. There is a Tab button, and most code editors indent automatically for you, but still it makes me sad to see poorly written code.

Also Variable naming is a big one for me. I don't want to have $thisisalongvariablename as a variable as opposed to $longvar or something along those lines. I do more of the server side programming, not so great with the designing, but I do know how to use (and the benefits of!) using CSS and divs and/or tables where needed. I agree with WebmasterX, tables are meant for tabular data and should be used for that, and that only.

A great reference on using tables for design layouts is this site. The url and content of the page says it all. :P

On another note, main CSS files should be structured, but I have seen some larger sites with CSS written all on one line, this is probably server generated CSS (which isn't really that hard to have a server side language format it, if you ask me).

End result of this post? Probably a chuckle from the link and unformatted/poorly formatted code = both bad and lazy. There is no excuse for it, IMHO.

Quote

why has coding become so politically correct?

I blame these guys: http://www.w3.org/
Better question is when are all the browsers going to support the same standards the same way? (Never, I know.)

This post has been edited by nrsocial: 12 January 2010 - 02:13 AM

0

#4 User is offline   WebmasterX 

  • Member
  • PipPip
  • Group: Members
  • Posts: 18
  • Joined: 16-January 09
  • Thanked: 2
  • Gender:Male
  • PHPFox Version:None
  • Country Flag:United States of America (USA)
Kudos: 8
Neutral

Posted 12 January 2010 - 10:26 PM

I think identifying bad Javascript, and bad PHP is pretty easy like xhtml, just look at the code, like javascript that's outdated tends to look like

<script>/*Ja Ja Ja*/</script>
<!-- or -->
<script language="Javascript"></script>


Up-to-date Javascript IMO is with frameworks like jQuery, now don't get me wrong you can be a good coder without it and don't need it for the simple things but if you know jQuery it's a bug plus just like if you know CakePHP with PHP or other frameworks it shows experience and skill.

PHP Same kind of deal the worst coders will code like

<? echo "Hi"; ?> //or
<?=$var?>


  • Short Tags (Depreciated; gone in PHP 6)
  • Double quotes used w/o variable or new line markers


If even seen people doing

<?php echo "$variale"; ?> // so USELESS!


Variable naming is important for me too, I like the way phpFoX standardized it personally

<?php
$sVarible = 'String Variable';
$iVariable = 1; // Integer Variable
$oVariable = new Object; //Object Variable
?>


I think it shows that you know what you're doing, and I think one of the biggest flaw for newbie or bad php coders is excessive use of user functions; functions should be used when you know you're going to need to reuse it over and over, and it has a complex task, I mean I've seen functions as useless as

<?php
function getdaarray($array)
{
print_r($array);
}
?>


I mean not only is the syntax all off (no return?) it's completely useless of a function, but new programmers don't understand that MORE code != better code; keep it simple! Plus all scripts that are in-depth and dynamic should be a part of a class anyway, so if you're going to use functions atleast make them part of a class structure and keep it organized.

This post has been edited by WebmasterX: 12 January 2010 - 10:26 PM

0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users