Felipe Gaucho's Blog

The IDEs are driving us crazy

Planet Earth, 2006 A.D.
Workstation: java.net
Module: Cejug-Classifieds
Status: active

If you had patient to observe the above report, you noticed some messy running on the code produced by the project team during february. The scenario is simple:

Seems familiar ? I guess so because almost every project I ever seen in my life suffers from configuration problems. If you are a member of a project in which every person could choose his own development environment, I'm sure you have painfull experiences with the code-style, integration and even the project communication. It is so common I decided to register this situation here in my blog.

Two other recent situations I experienced in my projects:

1. The project I'm working uses a modified template where the Line Wrapper was modified to 255 columns, instead of the traditional 80 columns. One week of good job and I decided to update my IDE - I installed the new version in my computer and keep working on the code. Few days later a colleague asked me: did you change the Line Wrapping rule?. Of course, as human being, I was tired and also excited with the new version of my IDE - and I simply forgot to redefine its defaults before start working.
2. A member of my Open Source project decided to contribute - he updated the CVS snapshot and fixed several open issues. Great job, unless a mute trap - the IDE he was using adopted the file encoding of his operational system, completely different from the project defaults. Nowadays, the project has part of its code in UTF-8 and part of it in Cp1252.

Machines: please don't think, just obey

The configuration problems seem ontological to computing and I can't imagine great solutions without much human interference. Despite that, several IDE vendors are designing heuristics to provide their IDEs the ability to guess what the humans are trying to do. This comfortable feature causes lazyness and ignorance about the development details - such as file encoding or code-style, for example. When a machine start taking decisions instead to ask the person what to do, the problems start. I think friendly IDEs as a great stuff, but it should be less pretentious about their ability to help us in our duties.

Some ideas: project descriptors like the ones used by Maven seem a great idea and something like that could be available for the IDEs. Imagine for a minute a specification of a XML Schema created by a consortium of IDE providers, in order to unify the project descriptors. Imagine now that every IDE forces the user to inform this default project descriptor in order to start a new project. Wonderful ? I guess so. Unfortunately, it seems far beyond the reality. For now, all responsability to reconfigure every new tools is still on humans and, you know, humans are not perfect.

Until we can figure out a solution for configuration problems, I enumerated a sanity checklist to help you to keep your team working together - if you know smart ways to avoid configuration problems, please let us to know.

Tricks to keep the team sanity:

Comments

• I agree with your alerts, but somethings can be better!
  Talking about the 80 columns in line wrap, i´m against this standard because it was thought when all computers use MS-DOS and the main development IDE was EDIT...
  Now we have hi-resolution screens and any explication can be talk for this "old" standard...
  Is tedious and bad to read an source when mid-screen is used..
  Sources like this are very bad in my mind:

  Object stuff = think.someMethod().otherMethod()
  .someOtherMethod()
  .otherMethodYet()
  .iHate80Columns();

  
  

  Posted by: raphaelpaiva on February 09, 2006 at 12:37 PM

• raphaelpaiva:
  There is still some use in having a limit.
  Not everyone has wide screens, some people's IDEs take up a lot of horizontal real estate, and some people just like to have their font set really big. When working on a team, it's important to consider how others will see your code.
  I usually find 100 characters is sufficient, especially if you're using 3 or 4 spaces to indent (tabs should be avoided). Some people go to 120 but I find even I've had problems with this at times and I have a pretty big res.

  Posted by: grlea on February 09, 2006 at 02:30 PM

• I agree with you.. 100 look good.. I usually use 120..
  I talk about 80 because I think it is an 'old standard' who mess up an good source read.

  Posted by: raphaelpaiva on February 10, 2006 at 03:51 AM

• remember: these 20 extra characters will cost you the portability of your code - any new IDE used by a member of your project could mess the code-style. This cost/benefit should be well thinked. You will need to modify the style descriptor of Checkstyle, PMD and any other verification tool .. You will have a lot of configuration problems just due to aesthetic preferences.. think about that...

  
  

  Posted by: felipegaucho on February 10, 2006 at 04:05 AM

• Why 20 caracters?
  Lets use plus 40 caracters(total 120)!
  May cause some problems with non-standard IDEs, but the code can be easier to undertand, more maintenable and beautier

  Posted by: raphaelpaiva on February 10, 2006 at 04:45 AM

• Risking stating the obvious, does your project has a well defined coding and configuration standard and new developers are informed about those? You don't need a standard XML configuration for IDEs, just a checklist everyone can verify before starting.

  Most modern IDEs allow project preferences and settings to be stored inside the project filesystem and updated via CVS or other SCM. This helps prevent human mistakes.

  If the probem becomes more serious (with a larger developer base) checkstyle checks could become part of the standard build process and be considered errors, not warnings.

  And, for all people discussing how wide lines should be, remember some still like (or need) to review code using paper listings. Raphaelpaiva, I personally think sources the way you don't like much clearer. So any consensul the project has (or is imposed by the initiator) is likely to not please someone.

  Posted by: flozano on February 10, 2006 at 05:16 AM

• Another reason for controlling the chars/line is printing. Printing >100 chars/line portrait will wrap the lines and loose the code format.

  Posted by: ahabra on February 10, 2006 at 07:17 AM

• The key problem is code style, (e.g c style brackets) include formatters for the main IDE's under CVS

  Posted by: paultaylor on February 13, 2006 at 03:23 AM

• 80 works well when printing on older printers, and when using smaller screens, and in my experience development teams tend to get both of those...
  Shop I work now for example the entire company (including the instructors and salespeople who are out of the office 90% of the time) has 17" or 19" TFTs, usually 2 of them, but most programmers are stuck with 15" TFTs or 17" CRTs (which they'd likely not have gotten except that that's the minimum size allowed here by law for people working with computers fulltime), they're usually the old ones previously used upstairs.
  Our printers likewise are castaways from other departments.
  I've rarely seen it different, in whichever environment (I've worked in everything from in-house IT departments to software development shops to consultancy firms, it's the same everywhere).

  Personally I've no trouble with different people using different editors/IDEs as long as the code style used in any file is consistent (and preferably across files). I've grown extremely wary of enforcing overly strict style rules as they tend to make people unhappy (in one place the position of specific words in comments was mandated for example, and enforced by the VCS, that place also mandated that all procedures be placed in sourcefiles in alphabetical order).

  Posted by: jwenting on February 13, 2006 at 05:41 AM

• what drives ME crazy is the way this software ignores linebreaks...

  Posted by: jwenting on February 13, 2006 at 05:42 AM

• The subject of a very wonderful and distinct
  I thank you for continuing excellence
  Thank you

  =========================================================================

  ليبيا
  شباب ليبيا
  libya
  منتديات
  منتديات ليبية
  غرائب وحقائق
  أحاديث شريفة
  برامج اسلامية للجوال
  مفاتيح الديجيتل
  الشيرنج
  الرسيفرات
  كتب إسلامية
  خلفيات للموبيل
  الشعر الشعبي
  الصحة والطب
  طب اسنان
  كتب طب اسنان مجانية
  برامج طبية
  تعلم الإنكليزية
  اللغة الفرنسية
  طب الإعشاب
  الخواطرالادبية
  الازياء والمكياج
  تعليم الطبخ
  الاثاث الحديث
  مقاطع كرة قدم
  المصارعه الحرة
  اهداف كوره
  الفوتوشوب
  اروع البرامج
  الدوري الليبي
  خلفيات رياضية
  المصارعة
  كورة عربية
  كرة قدم عالمية
  الدوري الإيطالي
  الدوري الاسباني
  الدوري الإنجليزي
  صور المشاهير
  انواع الحلويات
  افلام كوميدية
  احدث الافلام
  افلام
  التقنية
  تحميل افلام
  برامج
  اخر برامج الجوال
  kaspersky
  أفلام كرتون عربية
  برامج برامج كمبيوتر
  برامج حماية
  برامج اختراق
  برامج صوت
  برامج تحميل برامج احدث البرامج
  محادثة
  خلفيات الطبيعة
  برامج مبايل للتحميل
  اخبار الفن
  احدث الافلام للتحميل
  تحميل افلام رعب
  ترجمةأفلام
  الكامات
  برامج جوال
  برامج محاسبة
  برامج
  kasper
  games
  برامج
  برامج
  انترنت
  برامج صوتية
  شبكات الحاسوب
  خلفيات للويندوز
  تطويرالمواقع
  العاب
  العاب الفيديو
  games
  شفرات
  برامج مسنجر
  خلفيات شاشة
  صور ترحيبيه
  الفوتوشوب
  خلفيات طبيعة
  تطويرالمواقع
  الفوتوشوب
  مقاطع البلوتوت
  مسجات ليبية
  خلفيات
  الفلاش
  التصميم الثلاثي
  برامج الجوال
  العاب الجوال
  فيديو كليب
  مسجات
  ترددات ستالايت
  نغمات
  

  Posted by: libyan on May 30, 2008 at 03:25 PM

• Thanks so much for this! This is exactly what I was looking for.
  ///////////////////////////FLV to AVI converterFLV to WMV
  FLV to MPEG
  FLV Converter
  SWF to FLV
  M4V converter
  Ipod to PC
  Ipod to PC transfer
  DVD to iPod AVI to SWF site has all solution on FLV to SWF,
  WMV to SWF, MPEG to SWF,
  3GP to SWF, DivX to SWF,AVI to FLV
  and other video to SWF, FLV ecoded by Java.
  May it Gadgets helpful To your lifestyle... Enjoy！
  

  Posted by: quinceseed on June 19, 2008 at 08:13 PM

This work is licensed under a Creative Commons License.