diff --git a/HACKING b/HACKING
index 8158c34ed7..b4bbdca31f 100644
--- a/HACKING
+++ b/HACKING
@@ -1,126 +1,126 @@
 Since 1999, people have been hacking on Krita. Everyone brought their
 own coding style, their own code conventions, their own likes and
 dislikes. Me, (Boudewijn that is), I like indents of four spaces, and
 no scope prefixes for variables. However, in the interests of
 consistency, these are the rules new code should adhere to:
 
 See also http://techbase.kde.org/Policies/Kdelibs_Coding_Style -- that document
 is leading.
 
 Qt vs STD vs Boost:
 
     In general, use the Qt classes wherever possible, even if someone tells you
     that the STD class is better or whatever. We're dealing with a big project
     with lots of developers here and we should keep the code as consistent and
     easy to grasp as possible. Since people need to know Qt in the first place,
     keep to Qt. Discuss deviations on #krita
 
 C++11 and C++14
 
     Yes, but. Avoid lambdas. Avoid the new sig/slot connection syntax _unless_
     you are porting all of Krita to the new syntax. Sure, it has some advantages,
     but having two different ways of doing the same thing is begging for trouble
-    and comprehension problems. For now, keep using foreach, we're using it all
+    and comprehension problems. For now, keep using Q_FOREACH, we're using it all
     over the place. auto is fine, when using in for loops. Don't go overboard
     using it in other places. 
 
     Before using other new features, discuss on #krita so we can expand this list.
 
     Our minimum gcc version is 4.5, shipped with Ubuntu 12.04
 
 
 Indentation
 
 	With four spaces. Use the default kdelibs indentation 
     (http://techbase.kde.org/Policies/Kdelibs_Coding_Style)
 
 Includes
 
 	Avoid as much as possible #includes in header files; use forward declarations
 	of classes.
 
 Initializers
 
 	Avoid as much as possible initializers in the body of the constructor. Use
 	initializer lists instead. Write the initializers as followed:
 
     Class(A a, B b)
         : Subclass(a)
         , m_b(b)
     {
     }
 
 Scope prefixes
 
 	Use only m_ for class-level variables. No other scope prefixes; no g_, l_,
 	no 'p' for pointer variables.
 
 Shared pointers
 
 	Use shared pointers wherever possible.
 
 Getter/setter
 
 	Krita doesn't use Qt's properties -- yet. If you want to introduce use of
 	properties, convert any and all classes in Krita before committing.
 
 	Getter/setters are named 'x() for getters and setX(int x) for setters. If you
 	come across violations of this rule, change the code.	
 
 Class naming
 
 	If you use a well-known design pattern, name the class according to the design
 	pattern. All files should start with 'Kis', all classes with the 'Kis' prefix.
     This filename should be the same as the classname: KisNewClass.h, KisNewClass.
 
 Function naming
 
 	Functions should be named in camelBackedFashion, to conform to Qt's standards.
 	If you encounter functions in c_style_like_this, feel free to rename. Also:
 	verbNoun -- i.e., rotateLayer, not layer_rotate. The latter is a true c-ism,
 	introduced by a language that needs to prefix the 'class' name to every function
 	in order to have something that not quite OO.
 
 Variable/Parameter names
 
 	Variable/parameter names start with a lower case letter. A name composed of different
 	words is done in camelBackedStyle.
 
 Designer
 
 	Krita has started to use designer. All dialogs and all widgets that have a layout
 	manager must be done in designer. Do not add code or signal/slot connections
 	in designer.
 
 Enums
 
 	All enums should be prefixed with 'enum'.
 
 Namespaces
 
 	Currently, we only use anonymous namespaces for things like undo
 	commands. For the rest, some classes have a 'Kis' prefix, others don't. This should
 	be made consistent, and we might want to use namespaces to keep all of Krita
 	inside.
 
 Files and classes
 
 	It's preferred (and strongly preferred) to have only one class per .h/.cpp file.
 	(Which is logical, because otherwise you won't be able to keep to the naming scheme.)
 
 Spaces
 
 	Keep the source airy and open. In particular, there should be empty lines between function
     declarations and definitions.
 
 Slots and signals
 
 	Prefix slots with slot and signals with sig: slotUpdateSelection, sigSelectionUpdated.
 
 Boolean operators
 
     Use the standard !, !=, ==, && etc style, not the "not", "and" etc. style. Keep krita code
     using one, easily recognizable, C++ style.
 
 
 Boudewijn Rempt