Extracting File Name from Named Variable in Batch File

I needed this in order to use REN, which takes a pathless file name as its second argument.

Pretty easy with numeric variables or for loop variables. Here’s for loop variables:

set fileNameWithPath=C:\mypath\myfile.myextension
for %%X in ("%fileNameWithPath%") do set fileName=%%~nX
echo %fileName%

Here’s how to make a named variable into a numeric variable, by passing it to a subroutine.

set fileNameWithPath=C:\mypath\myfile.myextension
call :extractFileNameToVariable "%fileNameWithPath%" fileName
echo %fileName%
goto :EOF

:extractFileNameToVariable
set %2=%~nx1
goto :EOF

Opera/Mac File Input Opacity

Just to spread the word here and save some of you the frustration.

You may have found out about the smart way to style a file input. Check out the great article on Quirksmode.

Well, it doesn’t work in Opera/Mac. I tried it today with version 9.64. A lucky stumbling upon this article provided the solution.

To make Opera accept a file input’s opacity: 0 CSS rule, add border: none to the file input’s list of CSS rules.

Generic Parameter Antipattern

Now that I’ve had a chance to work with both Java and .NET generics, I must admit I like the runtime presence of generics in .NET. Java generics exist only to enhance compiler time checks and type erasure removes these from the binary class file — in all but metadata form for IDE code completion. In .NET, on the other hand, the generated MSIL retains the generic types, which become runtime metadata.

This, unfortunately, opens the door to coding abuse. When passing Type-typed arguments to methods parameters, one can now shove the parameter in as a generic parameter. Like this: myEmployeeCollection.First<Employee>(). This is borderline terrible; if First hadn’t been an extension method, the generic type would have been known to the method. But investigate this next example:

myContainer.RegisterType<IMyService, CustomerService>();
IMyService myServiceInstance = myContainer.Resolve<IMyService>();

This is perversion. For just the small gain of not having to use the typeof operator, we lose readability. One can’t even use this consistently as a new form of parameter passing, because there will always be non-Type parameters around. Either way, this opens the door to inconsistency.

In fact, generics are supposed to specialize, or focus the scope of code. Historically, generics described template — generic — bundles of behavior. This use scope is engrained in the coding standards of a few generations. Code reuse was the primary goal, but the presence of generic behavior has always been a crucial aspect of generic. There was also a fortunate side effect; the reader had an indication of the specific use case of the generic type. If a code preprocessor (C++), the compiler (Java) or even the runtime (C#) benefited from this arrangement, so much the better. But the primary purpose was pretty specific.

We see nowadays an abuse of the generics feature at method level, where Type parameters that from a semantic stand point clearly deserve the title of method parameters, are passed instead as generic type parameters, for the sole reason of their ability to be used as such. This programming pattern hinders consistency, and makes other use cases difficult. If the generic type parameter is unknown at compile time, reflective methods must be employed to produce results with generic and non-generic methods.

The problem is exacerbated by the use of this anti-pattern in Microsoft code. The above snippet is part of the documentation of the Unity dependency injection framework. In fact we sometimes have to moderate our sprints towards novel and embrace the good that we’ve achieved so far.

Mac, Parallels and the Trash

Items on a Parallels virtual disk deleted from Mac’s finder and not from the guest operating system become stuck in Mac’s trash. It’s Parallels’ fault, but there’s no fix to this problem, even on build 5608 (June 9, 2008). To solve this issue, start Parallels, then drag the problem files from the Mac trash to the virtual disk mounted by Parallels. Delete the files in the guest operating system (for instance, in Windows Explorer).

If Parallels mounts no disk, you may need to configure Parallels to do it (Devices -> Shared Folders -> All Windows Disks). If you’re not sure which Trash files “belong” to Parallels, clear the Trash to remove all the items; those hanging around are probably the ones you need.

Programming Language Guidelines

The coder Mihai has switched back and forth between C# and Java a few times now. Whenever switching, you notice how your brain gets used to the conventions used hitherto… I just recently began work on yet another Java project and was being pounded with IDEA’s error highlights on the (lowercase) “string” variables. You get my drill.

As far as the aforementioned languages, here are a few major distinctions in terms of code style and naming conventions in the two languages:

Method capitalization – method names in Java are camelCase, whereas in C# they are PascalCase.

Namespace naming – packages in Java begin with the TLD followed by the company name, usually similar to the website (com.mycompany.myproduct); in C#, a similar convention exists, although without the initial TLD component (MyCompany.MyProduct).

Prefixes – Java promotes no prefixing of any kind; C# luckily ruled out against Simonyi’s hungarian notation, or against the C prefix on class names sometimes seen in C++ libraries, but has voted for an I prefix on all interface names.

While most of us will not need to worry about this transition, there are a few cases in which you’ll find yourself in this situation. You may be be asked to port code from one language to another. What, then to do about the guidelines? They’re just guidelines, right? It’s not like they are formally enforced, so who cares?

Actually, it’s not quite like this. If you’re a religious follower of the code style and naming conventions, then you MUST follow the guidelines of the language at hand, even for those second-hand temporary bastards that you use only on occasion. Style leaks create inconsistencies and defeat the purpose of a naming convention. Enforcing a foreign convention on code is no better than not enforcing a convention at all.

A few years back, I wrote a utility in .NET; a Java aficionado was my direct supervisor. Of course I was consistent in following the guidelines and, since the tool was owned by my company, I naturally prefixed all my namespaces with MyCompany.MyToolName. Guess what? The guy had me change it to Com.MyCompany.MyToolName. Though he probably felt entitled to project Java conventions onto C#, he failed to see that, beyond his selfish universe, the future audience of the tool is acquainted to slightly different naming conventions, conventions that sink into the subconscious and trigger subtle associations.

More recently — just the other day — I skimmed through a Java XBRL library and found C++ and C# style code — not just C#, but both. It began with the I prefix on all the interfaces and ended with m_ and s_ prefixes on all class fields.

Required reading:  Java code conventionsC# naming conventions.