• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Documentation frustrations
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Documentation frustrations


  • Subject: Re: Documentation frustrations
  • From: Tim Conkling <email@hidden>
  • Date: Wed, 6 Jul 2005 14:06:45 -0400

On Jul 5, 2005, at 2:51 PM, Chris Hanson wrote:

On Jul 5, 2005, at 9:46 AM, Brandon Sneed wrote:

Despite VS.NET's UI being awful, writing code that works is made extremely easy by the good quality documentation and automation of common tasks.


Can you elaborate on your latter point (automation of common tasks) a bit?


-- Chris

I'd like to chime in here. I'm a long-time hobbyist Mac programmer (about 8 years). Before 6 months ago, I'd never done any Windows development. I've just recently completed my first job out of college. It was a 6-month contract position with IBM, developing the client front-end for some software that will be used by telephone reps. The client team used VS.NET 2003 and C# for all development. Despite having no experience with the IDE, language, or .NET framework when I arrived on the project (about midway through its development), I was doing meaningful project development within about a week. I would like to say this is because I'm a brilliant developer, but it's really due to Visual Studio's time-saving features. It's not my intent to sound like an MS cheerleader here -- in my defense as a Mac diehard, I will say that VS is the only MS product that has ever impressed me. It has many problems (many bugs, an irritating, overly-busy UI, and a poor (IMO) interface editor), but it does a few things very well:


- Code-completion. The completion list pops up instantly as soon as you type a period after an object (I was working in C#). For each method entry in the completion list, the popup window gives you a description of the method. If the method has overloads, you can cycle through the descriptions and parameter lists for them. When you choose a particular method, it fills in the name for you and rather than filling in placeholders for the parameters, it keeps the completion window up. After filling in a parameter and typing a comma, the completion window highlights the name of the next parameter that the method expects, and gives you a description of it. Most of the .NET framework is documented in this manner, and if you document your own code, you will see that documentation in the completion window.

- Auto-generation of code. As somebody already mentioned, double- clicking on a interface element in the interface editor will create the skeleton of a click event handler in the appropriate source file, and will fill in the event subscribe/unsubscribe code. If you are manually subscribing to an event (perhaps one that is not UI- related), the editor will detect this and offer to fill in what it can. Similarly, if you are overriding a method in a superclass, the editor will automatically write code for you if you want. These processes don't interrupt your workflow at all and they are quite intuitive to use.

- Auto-detection of incorrect code. Anyone who has used MS Word before is familiar with its red-squiggle-underlining of misspelled words. The VS editor does the same thing with mistyped code, and it's surprisingly fast and accurate. Obvious things like missing semicolons and parentheses are caught, but so are less-obvious things like mistyped variable names.

- Easy-to-use debugger. I still can't get Xcode to print meaningful information for my std::string variables, for example (in the summary column, I just get the custom formatter string printed in gray: size= {(int)$VAR.size()} "{(char *)$VAR.c_str()}":s). VS's debugger works, and makes it easy to find the information you're interested in. For example, you can right-click a variable in the debugger's source view and choose "Quick Watch", which opens a new window where you can view just that variable (and, if it's an object, all its members). Or you can drag a variable from the source view to your own custom "watch" window, which contains a subset of variables that you're interested in.

- Speed. There's not much to elaborate on here. We know that the Xcode team is working to give us a faster editor, compiler, and debugger. CodeWarrior is a good benchmark to shoot for. VS should also be a benchmark. There is no editor slowdown. Compile times are incredibly fast. The debugger starts quickly.

Tim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Documentation frustrations
      • From: Thierry Faucounau <email@hidden>
References: 
 >re: Documentation frustrations (From: George Warner <email@hidden>)
 >Re: Documentation frustrations (From: Brandon Sneed <email@hidden>)
 >Re: Documentation frustrations (From: Chris Hanson <email@hidden>)

  • Prev by Date: Re: Weird ending error XCode 2.1
  • Next by Date: Help files in Xcode shows up as html and nothing to find
  • Previous by thread: Re: Documentation frustrations
  • Next by thread: Re: Documentation frustrations
  • Index(es):
    • Date
    • Thread