SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 57
  1. #1
    SitePoint Member
    Join Date
    Feb 2007
    Posts
    6
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Talking 40 signs you really are a lousy PHP programmer

    This is something I prefer to call my "programming list of shame". Although having a formal university education with courses on software engineering, enterprise software architecture & database design I have been guilty of every single one of those things at one time or another. This is completely subjective & Eclipse oriented.

    Originally (with additional links) from http://www.reinholdweber.com/?p=19

    You are a lousy PHP programmer if you


    1. don't comment your code properly with something like phpDoc

    2. don't see the need and/or benefits of a good programming IDE like Zend Studio or Eclipse PDT

    3. have never used some form of version control like Subclipse

    4. don't adopt some coding & naming standards and general conventions and stick to to them at least throughout the project

    5. don't use a consistent methodology

    6. don't escape and/or validate properly input or sql queries

    7. don't plan your application thoroughly before starting to code

    8. don't use test-driven development

    9. don't program & test with error reporting on

    10. don't see the benefits of a debugger

    11. don't refactor your code

    12. don't keep the different layers seperated using something like MVC

    13. don't know what these stand for: KISS, DRY, MVC, OOP, REST

    14. don't return content but echo or print it from your functions or classes

    15. have never seen the advantage of unit tests or testing in general

    16. return HTML, not data, strings, or objects.

    17. hard code messages and configuration parameters

    18. don't optimize your sql queries

    19. don't use __autoload

    20. don't allow intelligent error handling

    21. use $_GET instead of $_POST for any destructive actions

    22. don't know how to use regular expressions

    23. you've never heard of sql injection or cross-site scripting

    24. don't allow simple configuration, can be parameters passed to a class’s constructor, set/get methods called later, or constants defined at a runtime.

    25. don't understand the benefits and limitations of Object Oriented Programming

    26. misuse OOP / everything you write , no matter how small is OOP

    27. you think reusable software equals/requires your code to be OOP

    28. don't choose intelligent defaults

    29. don't have one single configuration file

    30. don't want the file contents to be seen, but give it a .inc extension instead of .php

    31. don't use a database abstraction layer

    32. don't keep it DRY, Don't repeat yourself. If you have to copy and paste or duplicate something your design may be off.

    33. don't make a function/class/method do just one thing and don't make them interact.

    34. don't try to take advantage of OOP specific features like abstract/interface classes, inheritage polymorphism & access modifiers.

    35. don't optimize your application design with established design patterns

    36. don't allow your user to define a base directory if you have multiple files and/or directories

    37. pollute the global namespace, one option is to prefix the functions in your library with a common string

    38. don't allow a table prefix when using database tables

    39. use a separate template engine

    40. don't take a look at established php frameworks for inspiration, most of them have advanced web dev concepts and good code

  2. #2
    SitePoint Addict webaddictz's Avatar
    Join Date
    Feb 2006
    Location
    Netherlands
    Posts
    295
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by raindoll View Post
    19. don't use __autoload
    I beg to differ. require_once works just as well, and as __autoload is slower then manually requiring the files, I think it's best to require them on usage. I do however use __autoload at the first stages of a project, but that's because I'm a lazy son of a gun. When the time for refactoring comes however, I track the calls for __autoload and replace them with good ol' require_once's.

    EDIT:
    Quote Originally Posted by raindoll View Post
    31. don't use a database abstraction layer
    While I'm at it Many people have tried to fully abstract the database from their code and many people found that it's just not worth the trouble. Off course, you should separate your database calls to a separate layer which - in essence - is also abstracting your database. Using a fullblown Database Abstraction Layer is not what I consider best practise. Separating the logic for distinct databases from all other logic however is.

    Quote Originally Posted by raindoll View Post
    35. don't optimize your application design with established design patterns
    There is no use in using design patterns if your application doesn't ask for it. A design pattern is no more then an abstract solution to a common problem. In my point of view, it doesn't make sense to apply a design pattern when the problem it solves is nowhere to be found. Design patterns are a way of achieving your goal, they are not the goal itself.

  3. #3
    SitePoint Addict
    Join Date
    Apr 2004
    Location
    Melbourne
    Posts
    362
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by webaddictz View Post
    I beg to differ. require_once works just as well, and as __autoload is slower then manually requiring the files, I think it's best to require them on usage. I do however use __autoload at the first stages of a project, but that's because I'm a lazy son of a gun. When the time for refactoring comes however, I track the calls for __autoload and replace them with good ol' require_once's.
    If you're claiming speed, then use include_once instead of require_once because it's faster (no file lookup).

  4. #4
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    lousy too

    some of the points are lousy too.

  5. #5
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by raindoll View Post
    10. don't see the benefits of a debugger
    If you need a debugger more than occasionally, it's a sign of insufficient test coverage. Robert C. Martin says you should forget how to use a debugger. I agree with him.
    Quote Originally Posted by raindoll View Post
    39. use a separate template engine
    Ugh. I would say, "...don't see the pros and cons of template engines".
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  6. #6
    SitePoint Enthusiast
    Join Date
    Oct 2006
    Posts
    37
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The problem with this post is that 'X signs that you are Y' posts are 99% of the time intended to be of comedic value. This one fails horribly at that.

    It should be named '40 tips to be a better programmer', and it should be updated to reflect that.

    However, the biggest problem with this is is it not constructive. It's useless because it doesn't say why.

    No one learns from this. I understand this was replicated from an existing page, but there is nothing of worth in here (besides the fact that a 1/3rd of the claims are subjective or just plain wrong).

  7. #7
    SitePoint Member
    Join Date
    Feb 2007
    Posts
    6
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    well, I think it is very constructive and a very good starting point for discovering more about the individual points. while there certainly are debatable points most of it comes from hard learned (subjective) experience. if the "why" would be explained sufficiently it would be a book and not a 2 mins-to-read blog post.

  8. #8
    SitePoint Addict silentcollision's Avatar
    Join Date
    Jun 2006
    Location
    New Zealand
    Posts
    388
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    41. You don't understand most of the above.

  9. #9
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    I couldn't resist going through this list. These lists are definitely useful, but you probably want them built from a body of opinion. Otherwise they end up too personal.

    Would you consider editing it down to the 20 everyone agrees on?

    Quote Originally Posted by raindoll View Post
    1. don't comment your code properly with something like phpDoc
    I rarely do this. In fact I only do it as a band aid for some failing of methodology elsewhere, or on public class APIs that have to be extended.

    Quote Originally Posted by raindoll View Post
    2. don't see the need and/or benefits of a good programming IDE like Zend Studio or Eclipse PDT
    The benefits mostly come from habituation, which applies to any development style. See the Facts and Fallacies book (by Glass). Tools give no more than a 30% boost, and that's for the best tools (e.g. refactoring browsers, top notch debuggers). From studies, most tools actually had small negative percentages when compared with simple text editors.

    My own experience with Eclipse has certainly been negative (when I have had to pair with someone using it). Not as bad as Emacs though. And before I get flamed by Emacs users, yes I have used it (for over a year) and I have some familiarity with Lisp.

    Quote Originally Posted by raindoll View Post
    3. have never used some form of version control like Subclipse
    Agreed. The command line is good enough for me.

    I would add an automated build to your list. From there a nightly build, and from there something like CruiseControl.

    Quote Originally Posted by raindoll View Post
    4. don't adopt some coding & naming standards and general conventions and stick to to them at least throughout the project
    If you mean code indenting and bracket placement - complete waste of time and insulting to the developers. PEAR is a good example of this stupidity.

    Naming conventions for classes/methods and agreeing on domain names is extremely important - a prerequisite to design together. You cannot code together without a shared vision, but it has to be clear enough that everyone can carry it in their heads at all times.

    Quote Originally Posted by raindoll View Post
    5. don't use a consistent methodology
    An imposed methodology won't go down too well either, but I agree with this. It's the duty of a developer to work within the system a team has chosen and not to resort to guerilla tactics, primadonna outbursts or work to rule sulks.

    Quote Originally Posted by raindoll View Post
    6. don't escape and/or validate properly input or sql queries
    Why SQL queries? If you have validated your input, the DB integrity is maintained in far more powerful ways than a few regex checks.

    For user input, I agree. Get a friend to try to break your app. Very unsettling .

    Quote Originally Posted by raindoll View Post
    7. don't plan your application thoroughly before starting to code
    Depends on the problem domain. How do you plan a spam filter?

    Planning as you go is legitimate. You do need planning in some form, unless you are "hacking" (which is occasionally valid too), but you don't always get the value at the beginning.

    I think choosing the methodology appropriately to the task and the team is the key. Planning can save an enormous amount of time (sorry XP people) if there is experience on the team already, and the problem is a predictable one. If it isn't, then all your planning is worth squat about three weeks later.

    Quote Originally Posted by raindoll View Post
    8. don't use test-driven development
    99% agree, but check out "clean room methodology". Ada/Eiffel have their own way too.

    Quote Originally Posted by raindoll View Post
    9. don't program & test with error reporting on
    I would say that this is up to the team. I don't really want to have to declare variables before I use them (e.g Ruby), or having to write isset() all the time. I suspect that the majority of developers would agree with you. I am happy work with it.

    Quote Originally Posted by raindoll View Post
    10. don't see the benefits of a debugger
    The only time I use a debugger is on segfaults (in C) and when I don't understand the language (in Perl). I always have to read the manual first, I use them so rarely. I prefer testing, and once the test fails all I usually need is some print statements.

    Quote Originally Posted by raindoll View Post
    11. don't refactor your code
    Agreed.

    Quote Originally Posted by raindoll View Post
    12. don't keep the different layers separated using something like MVC
    Always design with modules. MVC is not everything though. Check out the "Naked Objects" library for a different philosophy.

    Quote Originally Posted by raindoll View Post
    13. don't know what these stand for: KISS, DRY, MVC, OOP, REST
    Oops. What does REST stand for again?

    Quote Originally Posted by raindoll View Post
    14. don't return content but echo or print it from your functions or classes
    Actually we have a whole bunch of widgets that do exactly this. We added an assetOutputIs() method to our test case to test them, using output buffering. In this case we thought the inability to override them was offset by the simplicity of writing and using them.

    However, I am familiar with the anti-pattern you are trying to target.

    Quote Originally Posted by raindoll View Post
    15. have never seen the advantage of unit tests or testing in general
    OK, but a restatement of the TDD one, right?

    Quote Originally Posted by raindoll View Post
    16. return HTML, not data, strings, or objects.
    Is changing the presentation medium a flex point? Or likely to be in the future? I would say never returning HTML is likely to be overengineering. You are in danger of someone shouting YAGNI at you.

    Quote Originally Posted by raindoll View Post
    17. hard code messages and configuration parameters
    For error messages, this is complex. They have to be filtered, but the information originates deep within the application. As for messages, depends. If they are likely to change, then they have to all live in one place.

    Not sure what you are trying to attack here, and it's a bit of a sliding scale. Do you advocate DI for example?

    I would be suspicious of "define"s scattered throughout the code, so this I agree on. You might want to sharpen this one up.

    Quote Originally Posted by raindoll View Post
    18. don't optimize your sql queries
    I never optimise anything if it complicates the code, unless it's shown to be a show stopper. We have queries that have to tunnel through all sorts of views designed to abstract parts of the schema. I get 20+ rows sometimes when I run "explain", but mostly they run fine.

    Premature optimisation is the root of evil and all.

    Once you have found some slow parts of the application, and you've tweaked your caches, then you have to optimise. It's not that we don't optimise (it takes out a chunk of our time), but we don't do it blindly.

    I have to disagree with this one, as it actually encourages blind optimisation.

    Quote Originally Posted by raindoll View Post
    19. don't use __autoload
    I've never used autoload. Should I?

    Quote Originally Posted by raindoll View Post
    20. don't allow intelligent error handling
    This is so very hard, and not covered well in books. Erlang is the only environment wher I've seen this tackled thoroughly.

    Do you mean by the user?

    Quote Originally Posted by raindoll View Post
    21. use $_GET instead of $_POST for any destructive actions
    Cool.

    Quote Originally Posted by raindoll View Post
    22. don't know how to use regular expressions
    Yep.

    Quote Originally Posted by raindoll View Post
    23. you've never heard of sql injection or cross-site scripting
    Fair enough. This is domain knowledge for PHPers.

    Quote Originally Posted by raindoll View Post
    24. don't allow simple configuration, can be parameters passed to a class’s constructor, set/get methods called later, or constants defined at a runtime.
    Yuk! I think someone reading this may think lot's of options and flags on a class is a good thing. I certainly wouldn't encourage people to use setters, except inside a Builder.

    Isn't ReplaceFlagWithStrategy some kind of refactoring?

    Quote Originally Posted by raindoll View Post
    25. don't understand the benefits and limitations of Object Oriented Programming
    That's a tough one to achieve .

    Quote Originally Posted by raindoll View Post
    26. misuse OOP / everything you write , no matter how small is OOP
    More specifically?

    Quote Originally Posted by raindoll View Post
    27. you think reusable software equals/requires your code to be OOP
    For PHP, you have to move mountains to do it without OOP. The lambda/closure patches may change that (if accepted), but procedural coding will break down after a few thousand lines.

    Quote Originally Posted by raindoll View Post
    28. don't choose intelligent defaults
    Yep.

    Quote Originally Posted by raindoll View Post
    29. don't have one single configuration file
    One interface per class of user, maybe. After all, templates are a form of configuration file.

    Quote Originally Posted by raindoll View Post
    30. don't want the file contents to be seen, but give it a .inc extension instead of .php
    Yeah. You still see .inc examples all over the web though.

    Quote Originally Posted by raindoll View Post
    31. don't use a database abstraction layer
    This is blindly doing something for the sake of consistency. I've used everything from an ORM, to none, to a simple homebrew connection object, to a specialist stored proc. abstraction layer. This choice totally depends on the application.

    Sorry, I can't agree with this one.

    Quote Originally Posted by raindoll View Post
    32. don't keep it DRY, Don't repeat yourself. If you have to copy and paste or duplicate something your design may be off.
    True. Hard when put under pressure by the business.

    Quote Originally Posted by raindoll View Post
    33. don't make a function/class/method do just one thing and don't make them interact.
    So true. It's the hidden interconnections that kill you though. Can I add "33a. Thinks Singleton is a good thing."

    Quote Originally Posted by raindoll View Post
    34. don't try to take advantage of OOP specific features like abstract/interface classes, inheritage polymorphism & access modifiers.
    Developers should know about them, for sure.

    That said, I think most of these are of marginal benefit, and only if the team prefer these constructs. Frankly I find access modifiers a pain (I never use them in Ruby). I still don't understand the use of "final", except to declare that the developer thinks that his user is even more stupid than he is.

    Interfaces too are a tool. The design of FIT uses public classes. JUnit made clever use of inheritance.

    The main thing I think, is to imagine someone using your code and to ask others what they need. It's a usability problem, just as designing a web page is.

    Quote Originally Posted by raindoll View Post
    35. don't optimize your application design with established design patterns
    I think you should know most of the major design patterns.

    Most of them are about adding flex points, which may never be needed. The will add complexity if you try to make it flex around the wrong point. Most oppose each other - TemplatePattern versus Strategy for example.

    Quote Originally Posted by raindoll View Post
    36. don't allow your user to define a base directory if you have multiple files and/or directories
    Or use relative paths and add the application to the web server as a web server include. Rails for example. If you are on shared hosting I can see your point. But the world seems to be going the virtual server route.

    Quote Originally Posted by raindoll View Post
    37. pollute the global namespace, one option is to prefix the functions in your library with a common string
    The application writer owns the namespace, as they have the most use for it. Libraries/Frameworks should definitely prefix in some way. Of course PHP 5.3 will have namespaces. I look forward to excessive namespacing as point 41...

    Quote Originally Posted by raindoll View Post
    38. don't allow a table prefix when using database tables
    Uh? I assume this is for people on shared hosts who have only one DB login for their entire account. In that case you have no choice.

    If you are not in that situation, then prefixing is evil. Use a separate schema (or database in MySQL). Better yet, give the tables good names, so that you don't clash so much in the first place.

    Quote Originally Posted by raindoll View Post
    39. use a separate template engine
    This is something that will cause a 50/50 opinion split. I prefer a widget approach (dropped into raw PHP pages) for the kind of sites I build (complex ASPs).

    Quote Originally Posted by raindoll View Post
    40. don't take a look at established php frameworks for inspiration, most of them have advanced web dev concepts and good code
    True. PHP devs seem less inclined to reinvent the wheel now there are some established good quality frameworks.

    A lot of these are inspired by those outside of PHP of course: Struts, Rails, ASP, Spring. I would say a big factor in being a better developer is having used more than one language.

    I think there is a lot missing from your list. The "Pragmatic Programmer" would add some, as would Joel's list.

    Are you planning to refine it and make it a bit more comprehensive?

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  10. #10
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I would say "shame" is too strong a word and some of these points don't apply to every situation where PHP is used. Some of it is also borders on purist snobbery.

    Quote Originally Posted by raindoll View Post
    1. don't comment your code properly with something like phpDoc
    Yes that helps to make API docs automatically, but that doesn't necessarily make it easier to understand code you didn't write. If you follow sensible guidlines, it is perfectly valid to come up with your own comment format and guidlines.

    2. don't see the need and/or benefits of a good programming IDE like Zend Studio or Eclipse PDT
    I have gotten into, and seen many a debate on what IDE to use and there has never been a consensus on it, but there have been plenty of abusive comments akin to "If you don't use x you suck!".

    There are plenty of coders that swear by vim. It's whatever makes you most productive.

    3. have never used some form of version control like Subclipse
    Having not used a popular software package for such a thing does not constitute a "lousey" programmer.

    4. don't adopt some coding & naming standards and general conventions and stick to to them at least throughout the project
    Always a good thing but still "lousy" is a bit strong.

    8. don't use test-driven development
    How you test and what you test depends entirely on your environment.

    10. don't see the benefits of a debugger
    Again, use the tools that you are most comfortable for you. I do just fine debugging old school with a little help from Zend Studio's error highlighting.

    12. don't keep the different layers seperated using something like MVC
    So let me get this straight, if I am deploying a simple RSS reader (contact form, video player, etc.) on a site for a client, I'm a lousy programmer if I don't use Codeigniter or Zend to deploy it?

    15. have never seen the advantage of unit tests or testing in general
    Not every situation needs unit tests.

    16. return HTML, not data, strings, or objects.
    And what about classes that autogenerate forms or other markup for special purposes? How can a function or method return HTML if it isn't a string? Unless of course you mean echo it, which isn't a return, it's an echo.

    26. misuse OOP / everything you write , no matter how small is OOP
    If I want to use a mail class in a contact form, to re-use code and avoid writing the same damn thing over and over again. I'll damn well do it. I don't care what anyone says about it. This conflicts with number 12 BTW.

    27. you think reusable software equals/requires your code to be OOP
    On a scale of re-usability, floating functions rate second. There is nothing wrong with prefering classes or even statically called methods over functions, especially when there may be name collisions in the global namespace.

    31. don't use a database abstraction layer
    By their nature, db abstraction layers are good re-usable OOP tools. I prefer them, but once again, using the word "lousy" is a little strong.

    34. don't try to take advantage of OOP specific features like abstract/interface classes, inheritage polymorphism & access modifiers.
    OOP elitist, purist bulls**t. Not every situation calls for every little feature that someone thinks makes OOP what it is. If it is appropriate to use any one of those do it. Not all of those on the list apply to every situation.

    35. don't optimize your application design with established design patterns
    What if you're really smart and come up with your own?

    39. use a separate template engine
    Opinion. A debate far from over.

  11. #11
    SitePoint Member
    Join Date
    Feb 2007
    Posts
    6
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    well, reading some of the responses it gets there clearly is a necessity for a
    "40 signs you really are a lousy PHP programmer (most of the php experts can agree on Edition)" :-)

  12. #12
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    1 Thread(s)
    I came in here expecting something funny like this and instead bump into a purist mantra that reads like it was written by someone with a degree and little to no real world experience.

    Got a secret for you raindoll - the outside world doesn't give a rat's behind how pretty, elegant, maintainable, object oriented or whatever else your code is. They only care if it works. The faster you can write, the better your profits.

    And BTW, defining __autoload directly is so PHP 5.0. Use spl_autoload_register()

  13. #13
    SitePoint Enthusiast
    Join Date
    Nov 2007
    Posts
    97
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    hm, its very nice of the rule. but somehow they still like the way i do program

  14. #14
    SitePoint Enthusiast
    Join Date
    Feb 2008
    Posts
    83
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn View Post
    Ugh. I would say, "...don't see the pros and cons of template engines".
    Agree with you here.

    Not every project calls for a template engine, but they can definitely be useful. I was a bit skeptical until I used one myself, but after a couple weeks working with Smarty I found that I quite liked the way it separated the coding from the display/design.

    - Walkere

  15. #15
    SitePoint Enthusiast
    Join Date
    Jun 2002
    Posts
    35
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I will only comment on one thing I think I have wide experience.

    39. use a separate template engine

    After using Smarty for a couple of years I worked on a project with no template engine. It seemed really primitive to have php code lying inside tables and divs.

    I think that people tend to overuse php inside their html code and this makes the sites very difficult to maintain and re-design.

    Template engines are part of successful php programming for me. Unless you have build one of your own, that completely separates data from design then you should use one of the existing ones.

  16. #16
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    1 Thread(s)
    A template engine needs to separate design logic from business logic. This isn't the same thing as separating PHP from HTML. There is a place for PHP within the output templates so long as that PHP is solely concerned with how things look (and, presumably, would need to be thrown away when the layout changes anyway).

  17. #17
    SitePoint Evangelist
    Join Date
    Jul 2001
    Posts
    523
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    man, I really AM a lousy PHP programmer!

  18. #18
    SitePoint Enthusiast invalidsyntax's Avatar
    Join Date
    Feb 2008
    Location
    CALI
    Posts
    34
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    wow, THANKS FOR POINTERS FOR US NOOBS OPPS CAPS
    Python Noob

  19. #19
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft View Post
    The benefits mostly come from habituation, which applies to any development style. See the Facts and Fallacies book (by Glass). Tools give no more than a 30% boost, and that's for the best tools (e.g. refactoring browsers, top notch debuggers). From studies, most tools actually had small negative percentages when compared with simple text editors.

    My own experience with Eclipse has certainly been negative (when I have had to pair with someone using it). Not as bad as Emacs though. And before I get flamed by Emacs users, yes I have used it (for over a year) and I have some familiarity with Lisp.
    The tools have to be appropriate for the task and the methodology. For TDD, I want:

    • An extremely easy way to open the unit test(s) belonging to the code I'm working on.
    • An extremely easy way to run tests.

    And that's what I've been working on with Vim, using Ruby to "script" program the editor.

    I don't see the point of Eclipse for PHP. Handling complex dependencies in Java projects is another matter.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  20. #20
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    I have to admit, that was a good laugh. Most of this is opinionated garbage. I would say that the only good points are with validation.

    Seriously, you think that the IDE you use changes your programming skill? In my opinion, nothing beats a good NotePad++. Syntax highlighting is the only tool I need to assist with errors.

    As for the commenting - you can use whatever you want. As long as the next programmer understands it, no problem.

    Frameworks? Yes, they are good for a quicker build - but for a full project with a reasonable time-scale, it should be all coded by the team, for the project. Too many dependencies on classes which you don't use for my liking.

    As for the point about includes - you really shouldn't put them in the root folder anyway. My includes are always outside it.

    OOP comments - very contradictory. One is rightly saying you shouldn't use OOP for small tasks, and a few others are saying nothing should be done without it.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  21. #21
    SitePoint Addict
    Join Date
    Feb 2006
    Posts
    247
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    with a list like that we all probably sucks.
    I live in Madison. Where in the W1RLD do you live?

  22. #22
    SitePoint Member
    Join Date
    Feb 2007
    Posts
    6
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have to admit, that was a good laugh. Most of this is opinionated garbage.
    that's why the opening paragraph contains "This is completely subjective" but I'm glad I could put a smile on your face, that has to count for something

    Seriously, you think that the IDE you use changes your programming skill? In my opinion, nothing beats a good NotePad++
    this is serious flame war stuff so I won't go into this, may everyone use what suits him best & he thinks he is most productive with

    As for the commenting - you can use whatever you want. As long as the next programmer understands it, no problem.
    how would you know if the next programmer understands your custom made comment style, if you work on a serious application with 100000+ lines of code there simply is no excuse for not using something everyone knows or can learn quickly like phpDoc

    OOP
    should be read in given context which I admit needs more explanation

    the outside world doesn't give a rat's behind how pretty, elegant, maintainable, object oriented or whatever else your code is. They only care if it works. The faster you can write, the better your profits.
    well I'm glad I'm not your customer or the guy who has to maintain after you are gone :-)

    What if you're really smart and come up with your own design patterns?
    then you are clearly wasting your time reading this thread

    So let me get this straight, if I am deploying a simple RSS reader (contact form, video player, etc.) on a site for a client, I'm a lousy programmer if I don't use Codeigniter or Zend to deploy it?
    every given point has to be evaluated based upon the context of what you're doing, the same is true for comments about points contradicting themselves, they actually do not, they just depend on what you're doing, maybe some explanation on my part would have been nice


    If you need a debugger more than occasionally, it's a sign of insufficient test coverage. Robert C. Martin says you should forget how to use a debugger. I agree with him.
    then i am definitely out of his or your league, I have never worked on something where a debugger was not helpful

    with a list like that we all probably sucks.
    if you have learned one thing reading this list, no matter how wrong you find most of the stuff then it was worth writing it.

  23. #23
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by raindoll View Post
    that's why the opening paragraph contains "This is completely subjective" but I'm glad I could put a smile on your face, that has to count for something
    That may have been, but you definitely left the wrong impression with your choice of words.

    how would you know if the next programmer understands your custom made comment style, if you work on a serious application with 100000+ lines of code there simply is no excuse for not using something everyone knows or can learn quickly like phpDoc
    Yeah gee whatever did programmers do before phpDoc came out. No excuse? I don't think so. It's a great product but frankly I find hand written API docs to be easier to understand most of the time. phpDoc's strengths are in producing documentation for code out of the comments contained in them. The degree to which they are valuable to a programmer scanning the code itself is not particularly helpful over any other potential commenting system.

    As long as you list arguments and their types, what the function or method does and the return type, there is nothing about those comment conventions that are particularly special. It is up to the programmer to provide sufficient details.

    should be read in given context which I admit needs more explanation
    Practically the entire list is poorly worded to the point of being insulting.

    then you are clearly wasting your time reading this thread
    I'll give you this, you certainly have an ego. Design patterns are not developed for the purpose of forcing developers to adopt them. You seem to seek to suck all the creativity out of creating with code for the sake of some sort of religious-like conformity. I and many others here will not give up our creativity to blindly follow some OOP religion. That does not mean we do not care about quality code, but it does mean that yours or anyone else's opinion on what is proper programming procedure is NOT the be all and end all of what is proper programming procedure and technique.

    every given point has to be evaluated based upon the context of what you're doing, the same is true for comments about points contradicting themselves, they actually do not, they just depend on what you're doing, maybe some explanation on my part would have been nice
    That wasn't even close to the impression the list gave, and frankly I'm skeptical. I have seen the very same attitude from many others. In addition, you should apply the same logic to your entire list and it's philosophy. PHP is used in a wide variety of settings. It's not just the context of the code, but the type of work you do, the clients you work with, the type of users you cater to, the type of hardware you use and a number of other factors.

    I understand where someone for instance that has done nothing but programming for financial institutions, might wonder why anybody would ever want to interact with a database using anything but stored procedures. Someone in that position that is a reasonable socially well adjusted person, might come to this forum and see other programmers using strings of SQL or prepared statements in their code and kindly suggest that they TRY stored procedures for security, and perhaps ask someone why they are not using them.

    Someone in that position with an ego, and an unhealthy need to impress others, might burst into a thread yelling

    WHAT THE HECK DO YOU PEOPLE THINK YOU'RE DOING. HAVE YOU GONE NUTS OR ARE YOU JUST STUPID!!!!!!!!

    It's all in your attitude. If you have something to contribute fine, but if you are going to wag your finger and judge the intelligence and abilities of others here based on some anal retentive standard of coding, then your going to get flamed.

    then i am definitely out of his or your league, I have never worked on something where a debugger was not helpful
    This is no different then choice of development software. I rarely use one. Debugger features and techniques, originate from languages which require compiling before running the code. As compiling takes time, they make a great deal of sense in those languages. Since PHP is dynamically compiled, the benefit is not as great. Debugging using simple syntax and error highlighting that is present in many PHP IDE's and using echo, die, var_dump and print_r to monitor even complex scripts is not that difficult. I have found that my rate of errors has dropped considerably over the years. Not using a debugger has not been a problem in the least.

  24. #24
    SitePoint Member
    Join Date
    Feb 2007
    Posts
    6
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'll give you this, you certainly have an ego. Design patterns are not developed for the purpose of forcing developers to adopt them.
    I'm sorry, you completely misunderstood my comment
    then you are clearly wasting your time reading this thread.
    if you define new design patterns that add something to the countless established ones you clearly are ahead of someone who discusses the use of an IDE or comment style or the benefits of OOP.

  25. #25
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by raindoll View Post
    I'm sorry, you completely misunderstood my comment
    if you define new design patterns that add something to the countless established ones you clearly are ahead of someone who discusses the use of an IDE or comment style or the benefits of OOP.
    Again trying to gauge one's intelligence based on what they choose to discuss or the ideas that they espouse.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •