I think several people has experience this problem, and that's with enums.
So the problem is quite simple, Xcode handles indentation after enums quite strange, at first I thought it was my syntax, but it turns out that it's probably not (I'm not ruling that out just yet)
So here's what my code look like:
enum Signs : bool {
Positive = true,
Negative = false
};
<This is where Xcode suggest where my next line of code should be, which is one tab more then I expect.>
Anyone seen this problem and solved it?
This bug can be replicated 100% of the time by specifying a value for one of the enum members.
If you omit the = true, automatic indentation will perform correctly. This goes for any enum with any number of enum items. As long as one item has = someValue, the closing brace will be misaligned.
it's 2018 and the developers of XCode still haven't fixed this bug in Xcode 9.2. So, please file bug reports (Help menu -> Report an Issue), now that the method for reproducing it every time has been discovered.
I usually write my enums like this:
//Using your example
typedef enum {
kPositive,
kNegative
}signs;
There you won't have the indentation problem. But I can't answer why Xcode behaves like that.
Related
In Xcode 6 beta 7, my warnings are divided into two sections, for example if one is called "my app" the other would be called "my app project". I have fixed all warnings I have received in the "my app" section ( there were only 3-4). On the "my app project" section however, I have over 42,000 warnings! It has been this way since before I even wrote any code and created my empty project. I always assumed this was a beta issue but I would like to know if everyone else is experiencing the same thing. I am unable to even look at what the problems are as Xcode freezes when I try due to the overwhelming number of warnings.
The release notes provide some details into the errors, seems to be the evolution of Swift:
http://adcdownload.apple.com//Developer_Tools/xcode_6_beta_7_apzr94/xcode_6__beta_7_release_notes.pdf
From the release notes:
Swift Language
• A large number of Foundation, UIKit, CoreData, SceneKit, SpriteKit, Metal APIs have been audited for optional conformance, removing a significant number of implicitly unwrapped optionals from their interfaces. This clarifies the nullability of their properties, arguments and return values of their methods. This is an ongoing effort that started shipping in beta 5.
These changes replace T! with either T? or T depending on whether the value can be null or not null, respectively. If you find a case that was changed incorrectly, please file a radar and include the tag ‘#IUO’ in the subject line. Please do not file feature requests about APIs that are still marked as T!, we know about them.
If you encounter a method for which the return value is incorrectly considered non-nullable, or a property that is incorrectly considered non-nullable, you can work around the problem by immediately wrapping the result in an optional:
var fooOpt: NSFoo? = object.reallyMightReturnNil()
if let foo = fooOpt { ... }
I haven't had any issues like that in any of the releases including Xcode 6 Beta 7. Each beta release I usually end up with about 100 or so errors due to changes in syntax but they only take half an hour or so to go through and resolve.
When experimenting I often use if (true) {..} or if (false) {..} to section off chunks of code I'm playing with.
The problem is that compilers these days sometimes issue a warning about unreachable code. I then have to promote my code to something like if ((10 % 2) == 0), but then some smarter compilers catch this as unreachable too.. (And so a small arms race begins..)
How do I solve this problem?
Try moving it out of the code, using pre-processor flags:
#if false
.... code which won't get run ....
#endif
Some IDEs will even collapse such un-runnable blocks for you to keep them out of the way.
Why not just use some kind of "environment variable" to control this kind of thing? Make it a reall conditional then you're not fighting the compiler.
if ( environment.MODE_EXPERIMENT) {
experimental code here
}
Personally I try pretty hard to avoid doing this kind of thing, we have SCM systems that allow us to keep old versions of code, really shouldn't need to do this too much.
This should do:
if (atoi("1")) {
}
This can also be useful to generate any kind of constant.
Almost every single language has a version of if(false) { } that a compiler/IDE won't complain about. The most common (afaik) look like the following:
/*
int i = 0;
String s = "I will never be run!";
*/
Yes, comments. Multi-line comments, to be exact. Stopping blocks of code from being run are pretty much their second main purpose (after documentation). if(true), of course, is then handled by not using them.
You're trying to re-invent the wheel here, and I have no idea why.
What I like to do is remove all functions which has specific word for example, if the word is 'apple':
void eatapple()
{
// blah
// blah
}
I'd like to delete all code from 'void' to '}'.
What I tried is:
^void.*apple(.|\n)*}
But it took very long time I think something is wrong here.
I'm using Visual Studio. Thank you.
To clarify jeong's eventual solution, which I think is pretty clever: it works, but it depends on the code being formatted in a very particular way. But that's OK, because most IDE's can enforce a particular formatting standard anyway. If I may give a related example - the problem that brought me here - I was looking to find expressions of the form (in Java)
if (DEBUG) {
// possibly arbitrary statements or blocks
}
which, yes, isn't technically regular, but I ran the Eclispe code formatter on the files to make sure they all necessarily looked like this (our company's usual preferred code style):
if (DEBUG) {
statement();
while (whatever) {
blahblahblah(etc);
}
// ...
}
and then looking for this (this is Java regex syntax, of course)
^(\s*)if \(DEBUG.*(?:\n\1 .*)*\n\1\}
did the trick.
Finally did it.
^void.*(a|A)pple\(\)\n\{\n((\t.*\n)|(^$\n))*^\}
Function blocks aren't regular, so using a regular expression in this situation is a bad idea.
If you really have a huge number of functions that you need to delete (more than you can delete by hand (suggesting there's something wrong with your codebase — but I digress)) then you should write a quick brace-counting parser instead of trying to use regular expressions in this situation.
It should be pretty easy, especially if you can assume the braces are already balanced. Read in tokens, find one that matches "apple", then keep going until you reach the brace that matches with the one immediately after the "apple" token. Delete everything between.
In theory, regular language is not able to express a sentence described by context free grammar. If it is a one time job, why don't you just do it manually.
Switch to VI. Then you can select the opening brace and press d% to delete the section.
Very simple question that is apparently impossible to find a decent answer to: How can I make Visual Basic 6 stop changing my ^##*ing variable casing!?!
I know that the general opinion of a great many VB users is that this "feature" is actually quite helpful, but I doubt that they use it much with any source control system. This is absolutely INFURIATING when you are trying to collaborate on a project of any significant size with several other developers. If ignored, you produce thousands of false-positive "changes" to your files (even ones with no actual code changes!) that pollute the revision history and make it near impossible in some cases to locate the actual change that took place.
If you don't ignore it (like my office, where we have been forced to implement a "no unneeded case change" policy), you spend 5x the time you would normally on each commit because you have to carefully revert out VB's "corrections" on every file, sometimes reverting hundreds of lines to put in a one line change.
Surely there must be a setting, plugin, hack, etc. out there that can remove this unwanted "feature"? I am willing to take any method I can get as long as it doesn't require me to pick through piles of phantom diffs. And to squash a couple of complaints up front: No, I can't turn off case detection in my diff tool, that's not the point. No, we can't just make the case changes globally. We're working with hundreds of thousands of LOC being worked on by multiple developers spanning many years of development. Synchronizing that is not feasible from a business standpoint. And, finally: No, we cannot upgrade to VB.net or port to another language (as much as I would love to).
(And yes, I am just a tiny bit peeved at the moment. Can you tell? My apologies, but this is costing me time and my company money, and I don't find that acceptable.)
Depending on your situation adding
#If False Then
Dim CorrectCase
#End If
might help.
Here is a real world scenario and how we solved it for our 350k LOC VB6 project.
We are using Janus Grid and at some point all the code lines which referenced DefaultValue property of JSColumn turned to defaultValue. This was an opportunity to debug the whole IDE nuisance.
What I found was that a reference to MSXML has just been added and now the IDE picks up ISchemaAttributes' defaultValue property before the Janus Grid typelib.
After some experiments I found out that the IDE collects "registered" identifiers in the following order:
Referenced Libraries/Projects from Project->References in the order they are listed
Controls from Project->Components (in unknown order)
Source Code
So the simple fix we did was to create a dummy class/interface with methods that hold our proper casing. Since we already had a project-wide typelib we referenced from every project before anything other typelib, this was painless to do.
Here is part of the IDL for our IUcsVbIntellisenseFix interface:
[
odl,
uuid(<<guid_here>>),
version(1.0),
dual,
nonextensible,
oleautomation
]
interface IUcsVbIntellisenseFix : IDispatch {
[id(1)] HRESULT DefaultValue();
[id(2)] HRESULT Selector();
[id(3)] HRESULT Standalone();
...
}
We added a lot of methods to IUcsVbIntellisenseFix, some of them named after enum items we used to misspell and whatever we wanted to fix. The same can be done with a simple VB class in a common library (ActiveX DLL) that's referenced from every project.
This way our source code at some point converged to proper casing because upon check-out the IDE actually fixed the casing as per IUcsVbIntellisenseFix casing. Now we can't misspell enums, methods or properties even if we try to.
SIMPLE WAY: Dim each variable in the case that you want. Otherwise, VBA will change it in a way that is not understandable.
Dim x, X1, X2, y, Yy as variant
in a subroutine will change ALL cases to those in the Dim statement
I can sympathise. Luckily we're allowed to turn off case sensitivity in our version control diff tool!
It seems the VB6 IDE automatic case-correction occasionally changes case in variable declarations and references, perhaps depending on the order in which modules are listed in the VBP file? But the IDE doesn't tell you that the file needs to be saved. So the problem only shows up when you saved the file because of another edit. We briefly tried to prevent this by checking out all the files in a project and setting the case carefully, but it didn't go away.
I suppose you could list the variable names that are affected - the usual suspects are one letter names like "I", "X" and "Y", perhaps because they are used in standard event handlers like MouseDown. Then write an add-in that'll search for all declarations " As" and force the case to upper. Run the add-in on your modules before you check them in. You might be able to trigger the add-in to run automatically when you save in VB6.
EDIT: Something I've just thought of: adapt Fred's answer. From now on, every time you check in a file, add a block at the top to establish canonical case for the usual suspects. If nothing else, it's easier than reverting hundreds of lines by hand. Eventually you will have this block in every file & maybe then the problem will stop happening.
#If False Then
Dim I, X, Y ' etc '
#End If
I standardised the case across the codebase, normally by using the examples above (Dim CorrectCase), and removing it again.
I then triggered VB to save EVERY file, by doing a case sensitive search/replace of "End" with "End" (no functional change, but enough to get VB to resave).
Once that was done, I could then do a single commit to standardise the case, making it MUCH easier to keep on top of it at a later date.
In this example VB6 was changing the case of the following line following a typo I made when referencing a library: -
Dim MyRecordset As ADODB.REcordset
Ugly, and now every other instance of an ADODB.REcordset thus acquired the new misspelling. I fixed this as follows: -
Type in a new declaration as follows
Dim VB6CasingSucks AS ADODB, Recordset
Note the comma and space after ADODB. Hit [ENTER] for VB6 to check the line.
At this point all instances of REcordset change back to Recordset.
Delete your new declaration.
I don't know if this fix will help with enums/other variable names.
Specifically for controlling the case of enum values, there is a VB6 IDE add-in which may be helpful. Enums seem to have a slightly unique version of this problem.
As described in the link below:
The VB6 IDE has an annoying quirk when it comes to the case of Enum
members. Unlike with other identifiers, the IDE doesn't enforce the
case of an Enum member as it was declared in the Enum block. That
occasionally causes an Enum member that was manually written to lose
its original case, unless a coder typed it carefully enough.
...
However, if a project contains a lot of Enums and/or a particular Enum
has a lot of members, redeclaring the members in each of them can get
quite tedious fast. ...
Ref: http://www.vbforums.com/showthread.php?778109-VB6-modLockEnumCase-bas-Enforce-Case-of-Enums
...load and unload the add-in as needed via the Add-In Manager
dialog box. Usage is as simple as selecting the entire Enum block,
right-clicking and then choosing the "Lock Enum Case" context menu
item.
I have a similar problem:
in a bas module there I wrote :
Private sub bla_bla()
Dim K as integer
End Sub
so in a class module the Dim k as integer will automatically be replaced by IDE become 'Dim K as integer' <-- it's not logical but then:
I correct the bas module become:
Private sub bla_bla()
Dim k as integer
End Sub
then magically the problem in the class module was solved (still be k and not automatically replaced by IDE become K). Sorry I'm poor in English
I don't think there's any to do it. The IDE will change the case of the variable name to whatever it is when it's declared. But, honestly, back in the day I worked on several large VB6 projects and never found this to be a problem. Why are people on your development team constantly changing variable declarations? It seems like you have not established a clear variable naming policy that you enforce. I know your upset, so no offense, but it might be your policies that are lacking in this regard.
Unfortunately, according to this SO thread, alternate VB6 IDEs are hard to come by. So, your best bet is to solve this problem via policy. Or move to VB.NET. :)
Wow. I've spent a lot of time programming in VB6 and I have no idea what you're on about. The only thing I can think you're referring to is that intellisense will change the capitalization of variable names to match their declarations. If you're complaining about that, I would have to wonder why the hell they've been entered any other way to begin with. And if that is your problem, no, there's no way to disable it that I'm aware of. I'd suggest you, in one go, check out every file, make sure the caps on the declarations and uses of variables all match and check back in.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Years ago when I was starting a small development project, the other developers and I sat down and agreed on a compromise brace and indentation style. It wasn't anybody's favourite, but it was something that nobody really hated. I wrote a .indentrc configuration file to that style, and had a check-in trigger that would run indent on every file as it was being checked in. That made it so that it didn't matter what style you wrote your code in, it would end up being the group standard before anybody else saw it. This had the advantage of consistency. But I've never seen anybody else do it this way before or since.
So what say the rest of you? Great idea, or abomination?
I'd say good idea. I'd take it a step further and make everyone use the config file in their IDE so that they were writing in the agreed upon style by default. If they're going to have to look at everyone else's code in the neutral style, they might as well get used to it. Even their own code should be in the neutral style after one check-in check-out cycle, so why develop new code in their own personal style?
Adopting a neutral coding style is definitely a good idea. However, only enforcing the coding style when the source is checked in may or may not be a good idea (see also Bill's and Elie's answers below).
Using the check-in hook:
Pro: Allows coders to write however they wish, so they don't have to think about the standard or change the way they write code. This minimizes resistance to the policy, and won't negatively impact their productivity when writing code.
Con: Your coders may have only a passing familiarity with the neutral style, so you aren't getting the full benefit of everyone using "the same" style. If your programmers ever have to work together in a pair programming setup, they are still going to be subjected to one another's programming style on the screen, which is going to be different from their own style or the neutral style.
Going one step further, using the neutral style during development:
Pro: Encourages fluency in the neutral style, everyone can always read everyone else's code before and after it's checked in.
Con: You'll encounter more resistance from your developers doing it this way. Depending on your culture, it could be more trouble than it is worth.
If you limited it to enforcing style on braces and indentation, then I think it's a good idea. However, if you were to try to enforce every single formatting standard, then it probably wouldn't be. In my opinion, there are times when it makes sense to break the standard. For example, I prefer
int x = y * z;
to
int x = y*z;
because it's easier to read. However, I vastly prefer
int a = b*c + d*e;
to
int a = b * c + d * e;
because the spacing represents the order of operations.
So your policy of enforcing indentation and braces sounds really good. But if someone ever tried to blindly enforce other spacing rules, I don't think it would work well.
That sounds like a good idea. As long as the style you end up with is not something completely strange, that's a good way to make sure your developers use the style. And it has the added benefit that they don't have to code that way - it will get reformatted for them when they check in their changes. It would be nice to have a tool like that available that you can plug into your CVS (generic term).
We use TFS with a check in policy that runs a set of Stylecop rules. If your code doesn't pass, you can't check it in. Works very well indeed. Aside from a consistant style and good commenting throughout, it also seems to have increased the general quality of the code - perhaps because the developer is forced to describe what every method, event, etc does they are forced to think about the code more before check in.
Only an MS solution, but worthwhile if it's available to you.
The biggest problem with using automatic code formatters is when the code formatter can't handle every scenario.
For example, if you have lots of SQL in your code, you probably format the SQL automatically. But if your SQL is longer than one line (how long is a line, anyway?) then
you have to format it. So far I've yet to see a good formatter than can deal with this properly.
Example:
String sql = "SELECT * FROM USERS WHERE ID = ? AND NAME = ? AND IS_DELETED = 'N'";
vs
String sql =
"SELECT * " +
"FROM USERS " +
"WHERE ID = ? " +
" AND NAME = ? " +
" AND IS_DELETED = 'N'";
The second format is more readable when you have really long queries. Most formatters would de-format that into one long line up to the line length.
However if all you're doing is turning
if(x=1) print("blah"); else print("eep!");
into
if (x = 1) {
print("blah");
} else {
print("eep!");
}
then the formatter is ok. We do something similar at work; it isn't enforced by the CVS tool but rather by the IDE. Works reasonably well.
There is a project called EditorConfig can somewhat solve the issue. However, it currently only solves indentation issues.
EditorConfig contains plugins for many different editors, and a file format standard. By creating an .editorconfig file in the root of your project, and installing the corresponding plugin, the editor will format your code when you type them.
This is a general way (unlike indentrc, not limited to C/C++), but you can still take a look at this solution.
I believe you have decided on your development environment by now. If you use Eclipse you can enable the Format Source save action on the Java editor, which reformats at every save. The major benefit from this is that source chances are marked in your source repository at the time when they were done, not when the source was reformatted later.
Make it an automatic step. You will appreciate it later.