This thread is what you do with solutions where some projects are written in VB.NET, others in C#. It started from discussion about avoiding Microsoft.VisualBasic namespace.
Also what you do to simplify your and your colleagues process of compatibility of source code while creating not only mixed-lang solutions, but also solutions that will run on different platforms like Windows and Linux.
Obvious choice for many developers is to use single language and stick to it, but the reality is more complex. There are legacy products written in other languages, frameworks and platforms. So it is hard to stick to C# as "we will do Linux projects" and discard years of work creating apps. Another reason to mix languages are existing libraries, created during the years and the lack of time to rewrite.
For me the most important rule is to keep code clean and near to the framework and avoid language specific syntax that may require much more time to learn for developers that know better the "other" language. It is like more specific coding style rules that can help future development, bugfixing and general migration to other platforms.
As thread starter, I will give my examples first. Of course, all these are personal preferences and are meant to use and have good development mood instead being annoyed by ugly code :-)
------------------------
VB.NET and VB6: Always specify method parameters if they are ByVal or ByRef, even VS.NET proposes to remove as unnecessary. The reason always to write it is the difference VB.NET and VB6 handle parameters when these keywords are omitted (default in VB6 is ByRef and in VB.NET is ByVal). Having old projects that rely on .NET COM objects risks blind copy/paste of method definition from VB.NET code to VB6 to introduce unexpected problems when accessing something by reference instead by value.
VB.NET and C#: Always try to use .NET common libraries instead of the specific Microsoft.VisualBasic namespace ones like file routines (FileCopy()), Rnd(), string routines (Len(), Chr(), Asc()) and other similar ones as they will make migration to C# much harder. For files there is File class, strings have own class and so on.
VB.NET and C#: But sometimes fully avoiding Microsoft.VisualBasic is not good for compatibility. For example vbCrLf as new line character is much similar to C# "\r\n" and gives explicitly how new line is represent in code. Using Environment.NewLine is OS specific and code may become not working when library is moved from Windows to Linux for example.
VB.NET and C#: Always use Path.Combine to create full path names as it handles OS specific directory character (Windows uses \ and *nix uses /).
VB.NET and C#: Use similar code style rules. Local variables are prefixed with _, e.g.
VB.NET, VB6, C#: Use same flow of routines - top to bottom or bottom to top in all projects. This is related to old times when compilers need called procedure to be before the procedure where the call is (ehh, good old Turbo Pascal times). Most of the times I start using bottom to top style where called routine is above the caller. This is related to my "scrolling" habits from the past. But sometimes I just start from top to bottom as VS IDE auto-generates non-declared routines after the current (caller) code.
Any language: Explicit declare everything that may change its default declaration as happened with some langs in past.
------------------------
Can you show more examples and explain why you do this or that to help your development if you have such mixed lang environment?
Also what you do to simplify your and your colleagues process of compatibility of source code while creating not only mixed-lang solutions, but also solutions that will run on different platforms like Windows and Linux.
Obvious choice for many developers is to use single language and stick to it, but the reality is more complex. There are legacy products written in other languages, frameworks and platforms. So it is hard to stick to C# as "we will do Linux projects" and discard years of work creating apps. Another reason to mix languages are existing libraries, created during the years and the lack of time to rewrite.
For me the most important rule is to keep code clean and near to the framework and avoid language specific syntax that may require much more time to learn for developers that know better the "other" language. It is like more specific coding style rules that can help future development, bugfixing and general migration to other platforms.
As thread starter, I will give my examples first. Of course, all these are personal preferences and are meant to use and have good development mood instead being annoyed by ugly code :-)
------------------------
VB.NET and VB6: Always specify method parameters if they are ByVal or ByRef, even VS.NET proposes to remove as unnecessary. The reason always to write it is the difference VB.NET and VB6 handle parameters when these keywords are omitted (default in VB6 is ByRef and in VB.NET is ByVal). Having old projects that rely on .NET COM objects risks blind copy/paste of method definition from VB.NET code to VB6 to introduce unexpected problems when accessing something by reference instead by value.
VB.NET and C#: Always try to use .NET common libraries instead of the specific Microsoft.VisualBasic namespace ones like file routines (FileCopy()), Rnd(), string routines (Len(), Chr(), Asc()) and other similar ones as they will make migration to C# much harder. For files there is File class, strings have own class and so on.
VB.NET and C#: But sometimes fully avoiding Microsoft.VisualBasic is not good for compatibility. For example vbCrLf as new line character is much similar to C# "\r\n" and gives explicitly how new line is represent in code. Using Environment.NewLine is OS specific and code may become not working when library is moved from Windows to Linux for example.
VB.NET and C#: Always use Path.Combine to create full path names as it handles OS specific directory character (Windows uses \ and *nix uses /).
VB.NET and C#: Use similar code style rules. Local variables are prefixed with _, e.g.
Code:
Private _serverURL As String
private string _serverURL;Any language: Explicit declare everything that may change its default declaration as happened with some langs in past.
------------------------
Can you show more examples and explain why you do this or that to help your development if you have such mixed lang environment?