Top tips-and-tricks Questions

List of Tags
Serhat Özgel

This came to my mind after I learned the following from this question:

where T : struct

We, C# developers, all know the basics of C#. I mean declarations, conditionals, loops, operators, etc.

Some of us even mastered the stuff like Generics, anonymous types, lambdas, LINQ, ...

But what are the most hidden features or tricks of C# that even C# fans, addicts, experts barely know?

Here are the revealed features so far:




Language Features

Visual Studio Features


Methods and Properties

Tips & Tricks

  • Nice method for event handlers by Andreas H.R. Nilsson
  • Uppercase comparisons by John
  • Access anonymous types without reflection by dp
  • A quick way to lazily instantiate collection properties by Will
  • JavaScript-like anonymous inline-functions by roosteronacid


Answered By: ageektrapped ( 755)

This isn't C# per se, but I haven't seen anyone who really uses System.IO.Path.Combine() to the extent that they should. In fact, the whole Path class is really useful, but no one uses it!

I'm willing to bet that every production app has the following code, even though it shouldn't:

string path = dir + "\\" + fileName;


Data Storage



Answered By: Andreas Grech ( 252)

Creating an HTML Element and keeping a reference

var newDiv = $("<div />");

newDiv.attr("id", "myNewDiv").appendTo("body");

/* Now whenever I want to append the new div I created, 
   I can just reference it from the "newDiv" variable */

Checking if an element exists

if ($("#someDiv").length)
    // It exists...

Writing your own selectors

$.extend($.expr[":"], {
    over100pixels: function (e)
        return $(e).height() > 100;

$(".box:over100pixels").click(function ()
    alert("The element you clicked is over 100 pixels height");

Which tricks do you know to make the experience with Eclipse faster?

For instance: I disable the all the plugins I don't need (Mylyn, Subclipse, …).

Instead of using a plugin for Mercurial I configure TortoiseHG as an external tool.

Answered By: VonC ( 138)

I agree with the previous answers:

The three most influential factors for Eclipse speed are:

  • using the latest Eclipse (3.7.1)

  • launching it with the latest JDK (1.7, which does not prevent you to compile in your Eclipse project with any other JDK you want: 1.4.2, 1.5, 1.6 older...)

    -vm jdk1.6.0_10\jre\bin\client\jvm.dll

  • configuring the eclipse.ini (see this question for a complete eclipse.ini)

    -Xms128m -Xmx384m -XX:MaxPermSize=128m -Xss2m [...]


  1. referring to the jvm.dll has advantages:

    • Splash screen coming up sooner.
    • Eclipse.exe in the process list instead of java.exe.
    • Firewalls: Eclipse wants access to the Internet instead of java.
    • Window management branding issues, especially on Windows and Mac.

    But it can also have some drawbacks if you try to push the memory too high.

  2. The default memory taken by Eclipse is the combination of MaxPermSize and Xmx. Here up to 512 MB total, which is quite enough for a 1 GB memory computer.

We've been using WiX for a while now, and despite the usual gripes about ease of use, it's going reasonably well. What I'm looking for is useful advice regarding:

  • Setting up a WiX project (layout, references, file patterns)
  • Integrating WiX into solutions, and build/release processes
  • Configuring installers for new installations and upgrades
  • Any good WiX hacks you'd like to share
Answered By: Si. ( 157)
  1. Keep variables in a separate wxi include file. Enables re-use, variables are faster to find and (if needed) allows for easier manipulation by an external tool.

  2. Define Platform variables for x86 and x64 builds

    <!-- Product name as you want it to appear in Add/Remove Programs-->
    <?if $(var.Platform) = x64 ?>
      <?define ProductName = "Product Name (64 bit)" ?>
      <?define Win64 = "yes" ?>
      <?define PlatformProgramFilesFolder = "ProgramFiles64Folder" ?>
    <?else ?>
      <?define ProductName = "Product Name" ?>
      <?define Win64 = "no" ?>
      <?define PlatformProgramFilesFolder = "ProgramFilesFolder" ?>
    <?endif ?>
  3. Store the installation location in the registry, enabling upgrades to find the correct location. For example, if a user sets custom install directory.

     <Property Id="INSTALLLOCATION">
        <RegistrySearch Id="RegistrySearch" Type="raw" Root="HKLM" Win64="$(var.Win64)"
                  Key="Software\Company\Product" Name="InstallLocation" />

    Note: WiX guru Rob Mensching has posted an excellent blog entry which goes into more detail and fixes an edge case when properties are set from the command line.

    Examples using 1. 2. and 3.

    <?include $(sys.CURRENTDIR)\Config.wxi?>
    <Product ... >
      <Package InstallerVersion="200" InstallPrivileges="elevated"
               InstallScope="perMachine" Platform="$(var.Platform)"
               Compressed="yes" Description="$(var.ProductName)" />


    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="$(var.PlatformProgramFilesFolder)">
        <Directory Id="INSTALLLOCATION" Name="$(var.InstallName)">
  4. The simplest approach is always do major upgrades, since it allows both new installs and upgrades in the single MSI. UpgradeCode is fixed to a unique Guid and will never change, unless we don't want to upgrade existing product.

    Note: In WiX 3.5 there is a new MajorUpgrade element which makes life even easier!

  5. Creating an icon in Add/Remove Programs

    <Icon Id="Company.ico" SourceFile="..\Tools\Company\Images\Company.ico" />
    <Property Id="ARPPRODUCTICON" Value="Company.ico" />
    <Property Id="ARPHELPLINK" Value="" />
  6. On release builds we version our installers, copying the msi file to a deployment directory. An example of this using a wixproj target called from AfterBuild target:

    <Target Name="CopyToDeploy" Condition="'$(Configuration)' == 'Release'">
      <!-- Note we append AssemblyFileVersion, changing MSI file name only works with Major Upgrades -->
      <Copy SourceFiles="$(OutputPath)$(OutputName).msi" 
            DestinationFiles="..\Deploy\Setup\$(OutputName) $(AssemblyFileVersion)_$(Platform).msi" />
  7. Use heat to harvest files with wildcard (*) Guid. Useful if you want to reuse WXS files across multiple projects (see my answer on multiple versions of the same product). For example, this batch file automatically harvests RoboHelp output.

    @echo off  
    robocopy ..\WebHelp "%TEMP%\WebHelpTemp\WebHelp" /E /NP /PURGE /XD .svn  
    "%WIX%bin\heat" dir "%TEMP%\WebHelp" -nologo -sfrag -suid -ag -srd -dir WebHelp -out WebHelp.wxs -cg WebHelpComponent -dr INSTALLLOCATION -var var.WebDeploySourceDir 

    There's a bit going on, robocopy is stripping out Subversion working copy metadata before harvesting; the -dr root directory reference is set to our installation location rather than default TARGETDIR; -var is used to create a variable to specify the source directory (web deployment output).

  8. Easy way to include the product version in the welcome dialog title by using Strings.wxl for localization. (Credit: saschabeaumont. Added as this great tip is hidden in a comment)

    <WixLocalization Culture="en-US" xmlns="">
        <String Id="WelcomeDlgTitle">{\WixUI_Font_Bigger}Welcome to the [ProductName] [ProductVersion] Setup Wizard</String>
  9. Save yourself some pain and follow Wim Coehen's advice of one component per file. This also allows you to leave out (or wild-card *) the component GUID.

  10. Rob Mensching has a neat way to quickly track down problems in MSI log files by searching for value 3. Note the comments regarding internationalization.

  11. When adding conditional features, it's more intuitive to set the default feature level to 0 (disabled) and then set the condition level to your desired value. If you set the default feature level >= 1, the condition level has to be 0 to disable it, meaning the condition logic has to be the opposite to what you'd expect, which can be confusing :)

    <Feature Id="NewInstallFeature" Level="0" Description="New installation feature" Absent="allow">
      <Condition Level="1">NOT UPGRADEFOUND</Condition>
    <Feature Id="UpgradeFeature" Level="0" Description="Upgrade feature" Absent="allow">
      <Condition Level="1">UPGRADEFOUND</Condition>

Please Help me compile a list of Effective Android Programming techniques

  1. Don't forget to free resources after use.
    Lot of resources like Cursors are overlooked. Free them too.

  2. Don't Use magic Numbers.
    values[0] is meaningless. The framework provides very useful accessors like values[SensorManager.DATA_X]

  1. "Make use of onPause()/onResume to save or close what does not need to be opened the whole time."

    protected void onResume() {
    protected void onStop() {
  2. Make your Android UI Fast and Efficient from the Google I/O has a lot of useful UI Performance tips.

Answered By: Charles Merriam ( 202)

Here's my personal top twenty. I use this in addition to the usual lists from I could add another five, though the list is long enough.

  1. Add Two Numbers: Your first non-tutorial application should be to take two numbers and add them together. It sounds too simple. You will spend some hours getting the layouts, the callbacks, and onPause/onResume to work correctly. Do it.
  2. It is Java: You work in Java for most of your Android programming. Don't spend time praising it. Don't spend time complaining about it. Just work with it.
  3. Love RelativeLayout: Most of the tutorials use LinearLayout, but you will find that RelativeLayout is truly useful. Many layouts, like the GridLayout aren't used much at all. Play around with RelativeLayout. See an example from this question.
  4. Use fill_parent with a top level RelativeLayout: A surprisingly common and hard to find problem is putting a wrap_content in a top level RelativeLayout and then wondering why unrelated fields far down in the hierarchy are rendering strangely.
  5. Use empty layout items: You will often use empty items in your layouts just for positioning other layouts. For example, you might use an empty TextField, of width=0 and height=0 and centerInParent='True' just to anchor things relative to the middle of the screen. Also, you might have an empty TextField or LinearLayout so that you can give a layout_weight=1 to it and have it take up more screen space.
  6. Set a layout background color: If you are having trouble figuring out your layout, try setting the background colors on some objects. It can highlight your mistakes faster than other tools, and shows some surprises that the IDE red box doesn't always help.
  7. Download Apps-For-Android: This is a big chunk of useful source code for a half dozen applications. It can supplement the sample applications nicely and show different coding style solutions. Grab it using svn co apps-for-android-read-only
  8. Download the source: You need the Android source to solve some problems or, more likely, get past holes in the documentation. Your copy does not need to be perfect or kept up to date. You can learn to use the repo command, or just visit for a snapshot.
  9. Learn to search your source: The fastest solution to many problems is to find where a particular parameter is used in some other source. Put a copy or link to the sample applications, apps-for-android applications, and any other source you have under one directory tree. Use "grep -ir funky_parameter sample_code/" or your favorite searching routine to quickly find some code that uses that parameter.
  10. Use Eclipse: Even you have a favorite editor or IDE you have used for years, use Eclipse for Android development. It is good enough as an IDE and is really part of the development tools suite. Any time you spend trying to jury-rig your IDE to work is time you didn't code.
  11. Learn Eclipse: Learn a few new tricks with Eclipse every day. Some of my favorite commands were found reading this list and this question.
  12. Get help when starting out: The quantity of readable material can be overwhelming. Setting up the environment can be tricky. Going to an Android Meet-up or users group can help get over the initial hump.
  13. Code every day: Android code will be frustrating. Don't allow yourself to stop because you get stuck. Play around with the tools, step through a sample application, read one of the articles, or read a blog to ease the frustration. Then write some more code.
  14. Lurk on IRC: Connect your favorite IRC reader to's #android-dev channel. Leave it up in the background. Only ask questions after you have spent ten minutes trying to figure it out on your own.
  15. Use two monitors: Working on your laptop in the coffee shop will slow you down. You need to spread out windows. At very least, you will want a full screen Eclipse session, the emulator, and a browser with the tutorial to all be easily visible. Three screens may work even better.
  16. Reformat XML files: The layout editor makes a hash of the XML files. Use the 'source/format' command to put them in a reasonable form. You will want to check the "Eclipse/Windows/Preferences/XML/XML Files/Editor/Formatting/Split XML attributes each on a new line" check box. Then use shift-ctrl-F to format it.
  17. Edit XML files with the text editor: After the first couple of layout screens, stop using the slow moving 'properties' gui to change properties. Drop the items using the gui. Use the up/down arrows on the far right outline to get the hierarchy of views and layouts correct, then edit the XML file directly and use the ctrl-space shortcut to bring up possible completions and explanations of the properties.
  18. Plan on Piracy in the MarketPlace: Google has not made the MarketPlace a Happy Place. Apps are copied and reposted with changed names to funnel money around. Lots of scammers are trying to game the system in many ways. Don't plan on making a living solely from AppStore revenues nor plan on Google being responsive.
  19. Use LogCat: It can be difficult in Android to figure out 'what went wrong'. Run the application in the debugger and look at the logcat window. I found it worthwhile to add a new perspective with just a maximized logcat window. If you like to have a colored LogCat output in a separate window try this tool: Colored LogCat
  20. Explore the tools directory: There a lot helpful tools in the sdk's tools directory, such as hierarchyviewer and layoutopt. Each is helpful and there is no shortcut to learning about each tool one at a time.

I could add more if enough people chime in. I hope you find these tips helpful.

Adam Bellaire

What are some really useful but esoteric language features in Perl that you've actually been able to employ to do useful work?


  • Try to limit answers to the Perl core and not CPAN
  • Please give an example and a short description

Hidden Features also found in other languages' Hidden Features:

(These are all from Corion's answer)

  • C
    • Duff's Device
    • Portability and Standardness
  • C#
    • Quotes for whitespace delimited lists and strings
    • Aliasable namespaces
  • Java
    • Static Initalizers
  • JavaScript
    • Functions are First Class citizens
    • Block scope and closure
    • Calling methods and accessors indirectly through a variable
  • Ruby
    • Defining methods through code
  • PHP
    • Pervasive online documentation
    • Magic methods
    • Symbolic references
  • Python
    • One line value swapping
    • Ability to replace even core functions with your own functionality

Other Hidden Features:


Quoting constructs:

Syntax and Names:

Modules, Pragmas, and command-line options:


Loops and flow control:

Regular expressions:

Other features:

Other tricks, and meta-answers:

See Also:

Answered By: John Siracusa ( 54)

The flip-flop operator is useful for skipping the first iteration when looping through the records (usually lines) returned by a file handle, without using a flag variable:

  next if 1..1; # skip first record

Run perldoc perlop and search for "flip-flop" for more information and examples.

I know there is a standard behind all C compiler implementations, so there should be no hidden features. Despite that, I am sure all C developers have hidden/secret tricks they use all the time.

Answered By: tonylo ( 117)

More of a trick of the GCC compiler, but you can give branch indication hints to the compiler (common in the Linux kernel)

#define likely(x)       __builtin_expect((x),1)
#define unlikely(x)     __builtin_expect((x),0)


What I like about this is that it also adds some expressiveness to some functions.

void foo(int arg)
     if (unlikely(arg == 0)) {