“In the context of the Single Responsibility Principle (SRP) we define a responsibility to be “a reason for change.” If you can think of more than one motive for changing a class, then that class has more than one responsibility.”
— Bob Martin, The Principles of OOD
“A class should do the smallest possible useful thing; that is, it should have a single responsibility.”
— Sandi Metz, Practical Object-Oriented Design in Ruby
One of the things that is kind of annoying about regular expressions is that every programming language implements them slightly differently. If you can, find someone who can give you the low-down in this new language. Otherwise, you’ll have to stick with googling, which can take a while to figure out what you need. I’ll get you started with a few languages.
Two of my favorite and most helpful resources:
One of the easiest ways to get started with regular expressions in Ruby is via Rubular.com. This site provides a way to test regular expressions against any text, as well as a quick cheat sheet to help. RegExPlanet.com also has a Ruby tester that is in beta.
For help with Java, I really like using the tester at RegExPlanet.com. It does two really cool things.
Using regular expressions in JavaScript was where I really began using the pattern modifiers. If a regular expression is between two forward slashes, pattern modifiers are the letters that come after the last forward slash.
/hello/i
This regular expression will match the word ‘hello’ as well as capitalized ‘Hello’, and all caps ‘HELLO’. It will even match the super fancy ‘hElLo’, if you are into crazy stuff like that. The i modifier tells the regular expression to be case-insensitive.
Another really useful modifier for regular expressions in JavaScript is g, which stands for ‘global’. In JavaScript, regular expressions will find the first time it matches a pattern and then stop. Using the g modifier tells it to find ALL the instances where a string matches the given pattern.
I’ve learned a whole lot about regular expressions over the last year and a bit, and there are two ‘phrases’ for lack of a better term that are sort of like the nuclear option or like a blunt object, but will get me most of where I need to go.
.*?This is one of the most useful regular expression ‘phrases’ I’ve learned. It selects zero or more of any kind of character, including spaces, but isn’t greedy. (That just means that it’ll stop the first time it sees whatever is put after the question mark). The key limitation of this phrase is that it will not include new lines (though the exact implementation varies from language to language).
.+?Related to the first phrase, this one selects one or more of any kind of character, including spaces, but isn’t greedy. This is useful when something has to exist, but can be any number of things. Like the one before it, this (usually) doesn’t include new lines.
[\s\S]*?This ‘phrase’ is even more ‘powerful’ than the one above. This one selects zero or more of any kind of character, including all kinds of whitespace (yes, also new lines), but again, isn’t greedy. I used this one a LOT for a while, especially in Java.
I was having trouble getting a regular expression to select an section of HTML that was broken up onto different lines irregularly 1. Finally I figured out that I wanted to use \s*? (zero or more whitespace characters, not greedy) to account for the different amounts of spacing, but not to pick up any letters or other characters.
I’ve been working with case statements in Ruby, and I was having a difficult time getting it to do what I wanted.
Things I learned:
case (ex: case SOME_VARIABLE) can’t take logic after the when part of the statement.
Bad:
case thingie when thingie.match(/some regex/) # something cool happens end
Good:
case thingie when "a perfectly boring string" # something cool happens end
case CAN take logic after the when
Good:
case when thingie.match(/some regex/) # something cool happens end
So, I think that’s a really good question. And I think it depends on where you are in your career. I think when you are just starting out you have to dig deep, because it takes a while. You haven’t really done, I’m not talking about you particularly, but people in general who are just starting out, you’re learning a whole lot of things at the same time. And as a beginner, you’re going to have to learn those by experience. You’re going to sit there and try it and do different things, and put in the hours. So, maybe learning Ruby and Rails to the point where you are comfortable I think is the trick. So, the point where you can sit down and write an app and most of it just flows. And yeah, you got to stop and look up an API every now and then, but pretty much you know where you’re going and what you’re doing.
At that point of comfort, I think you then do two things: you carry on doing what you’re doing, but at the same time you fork off a little process I yourself to go and look at doing something else. And what you’ll find is that the second time you’re doing that deep dive, then it’ll be easier, because you’ve learned the techniques of learning, a little bit. And then the third time would be easier still. So, I think that as a beginner, you go deep. And you get to the point where you’re comfortable. And then you got to move back to something else where you’re not comfortable, do it again. And if you keep doing that, after a while it gets a lot quicker to pick these new things up because you’ve shown yourself how to do it.
I really like this articulation of how to balance depth with breadth and new things as a new/beginner programmer.
