Is lines of code a good measure of effort in effort-aware
models?
Emad Shihab a ,?,Yasutaka Kamei b ,Bram Adams c ,Ahmed E.Hassan d
a
Department of Software Engineering,Rochester Institute of Technology,Rochester,NY,USA
b
Graduate School and Faculty of Information Science and Electrical Engineering,Kyushu University,Fukuoka,Japan c
Lab on Maintenance,Construction and Intelligence of Software (MCIS),école Polytechnique de Montréal,Canada d
Software Analysis and Intelligence Lab (SAIL),Queen’s University,Kingston,ON,Canada
a r t i c l e i n f o Article history:
Received 2December 2012
Received in revised form 25June 2013Accepted 25June 2013
Available online 4July 2013Keywords:
Effort-aware prediction Prediction models Defect prediction
a b s t r a c t
Context:Effort-aware models,e.g.,effort-aware bug prediction models aim to help practitioners identify and prioritize buggy software locations according to the effort involved with ?xing the bugs.Since the effort of current bugs is not yet known and the effort of past bugs is typically not explicitly recorded,effort-aware bug prediction models are forced to use approximations,such as the number of lines of code (LOC)of the predicted ?les.
Objective:Although the choice of these approximations is critical for the performance of the prediction models,there is no empirical evidence on whether LOC is actually a good approximation.Therefore,in this paper,we investigate the question:is LOC a good measure of effort for use in effort-aware models?Method:We perform an empirical study on four open source projects,for which we obtain explicitly-recorded effort data,and compare the use of LOC to various complexity,size and churn metrics as mea-sures of effort.
Results:We ?nd that
using a combination of complexity,size and churn metrics are a better measure of effort than using LOC alone.Furthermore,we examine the impact of our ?ndings on previous effort-aware bug prediction work and ?nd that using LOC as a measure for effort does not signi?cantly affect the list of ?les being ?agged,however,using LOC under-estimates the amount of effort required com-pared to our best effort predictor by approximately 66%.
Conclusion:Studies using effort-aware models should not assume that LOC is a good measure of effort.For the case of effort-aware bug prediction,using LOC provides results that are similar to combining com-plexity,churn,size and LOC as a proxy for effort when prioritizing the most risky ?les.However,we ?nd that for the purpose of effort-estimation,using LOC may under-estimate the amount of effort required.
ó2013Elsevier B.V.All rights reserved.
1.Introduction
A large amount of research work has focused on predicting where bugs may occur in software systems [37].The main goal of this line of work is to prioritize quality assurance efforts to make effective use of quality assurance resources.
However,the adoption of software bug prediction research in practice remains low [16,13].One of the main reasons for this low adoption is the fact that,for a long time,these bug prediction models did not take into consideration the effort needed to act on the recommended artifact [16].In this context,effort means the amount of effort required to address (i.e.,unit test or code review)the recommended artifact (i.e.,?le or folder).This notion of effort is different from the work on the next-release problem (i.e.,given a set of parameters for a project how much effort is needed for the next release)[1,12]and from the work that focused at predicting the amount of time required to ?x a bug (e.g.,[36]).
To incorporate effort into bug prediction,recent work (e.g.,[22,3,23,19])studied the performance of effort-aware bug predic-tion models.These models typically use lines of code (LOC)as a de facto measure of the effort required to address bugs,since expli-cit effort is rarely recorded by development projects.The authors showed that when effort is considered in the prediction models,the usefulness of some prediction models (e.g.,models that use size to prioritize buggy locations)may be affected.However,they point out that perhaps there might exist better measures of effort than LOC [22].
To the best of our knowledge,previous work did not address the important question of what is the best way to measure effort in ef-fort-aware models?Yet,?nding a good estimator of effort is critical to the accuracy,and hence success of,effort-aware models in practice.
In this paper,we perform an empirical study on four Open Source Software (OSS)projects for which we obtain explicit effort
0950-5849/$-see front matter ó2013Elsevier B.V.All rights reserved.https://www.doczj.com/doc/3b2258747.html,/10.1016/j.infsof.2013.06.002
?Corresponding author.Tel.:+15854752949.
E-mail addresses:emad.shihab@https://www.doczj.com/doc/3b2258747.html, (E.Shihab),kamei@ait.kyushu-u.ac.jp (Y.Kamei),bram.adams@polymtl.ca (B.Adams),ahmed@cs.queensu.ca (A.E.Hassan).
data–namely JBoss,Spring,Hibernate and Mule and compare the use of LOC to other code and process metrics as measures of effort. First,we perform correlation analysis to examine the relationship between the various code and process metrics and effort.Then, we examine which of process metrics,code metrics or the com-monly used LOC measure best predict https://www.doczj.com/doc/3b2258747.html,stly,we examine the impact of our?ndings on prior research?ndings related to ef-fort-aware bug prediction.We aim to answer the following re-search questions:
RQ1:Does LOC correlate better with effort than other code and process metrics?
We?nd that LOC has a low correlation with effort in all four studied projects.Code metrics,in particular complexity metrics, have the highest correlation with effort.However,the overall correlation values for both LOC and complexity metrics remain relatively low.
RQ2:Is LOC a better predictor of effort than other code and pro-cess metrics?
We?nd that code metrics,in particular complexity metrics,are better predictors of effort than LOC in all four studied projects.
Moreover,combining LOC,complexity,churn and size metrics yields the best prediction results.
RQ3:How do our?ndings impact previous effort-aware bug pre-diction?ndings?
Revisiting prior effort-aware bug prediction work shows that for the purpose of ranking the most buggy?les,using LOC as
a measure of effort performs similar to our best effort predictor.
However,for the purpose of effort-estimation,using LOC under-estimates the amount of effort required compared to our best effort predictor.
To facilitate future studies,we are making our explicit effort data set available to the software maintenance research community.1
The rest of the paper is organized as follows.Section2surveys the related work.Section3describes our methodology.Section4 presents an exploratory analysis of the used effort data.Section5 presents the?ndings of our study.Section6discusses our?ndings and their implications.Section7lists the threats to validity and Section8concludes the paper.
2.Related work
In this section,we highlight the previous work and contrast with our work.The majority of the related work comes from the areas of software bug prediction and effort estimation.
2.1.Bug prediction
2.1.1.Standard bug prediction models
A large number of prior work uses code metrics to predict defective or fault-prone modules(e.g.,?les).The majority of this prior work shows that McCabe’s cyclomatic complexity metric [21]and the Chidamber and Kemerer(CK)metrics suite[9]can be used to successfully predict pre-and post-release bugs with high accuracy on both,commercial and open source systems [29,5,35,15,11,8,28,37].
Other work uses process metrics,such as the number of prior bugs or prior changes to predict fault-prone modules.This work shows that the number of prior changes to a?le is a better predic-tor of bugs than code metrics in general[14,2,20].More recently,Moser et al.[25]show that process metrics in general perform bet-ter than code metrics when predicting post-release bugs in Eclipse. Hassan[17]shows that using the complexity of code changes is a good predictor of bugs.
Although it has been shown that standard bug prediction can be bene?cial to improve the quality of software systems,its adoption remains low[13,16].Therefore,a number of recent studies have ar-gued that effort needs to be considered to improve the adoption of standard bug prediction research.
2.1.2.Effort-aware bug prediction models
Recent work examined the performance of software prediction models when effort is considered(i.e.,effort-aware bug prediction) [22,19,3,24].In all of these prior studies,LOC was used as the de facto measure of effort.The authors showed that considering effort yields different results from standard bug prediction(i.e.,the per-formance of models built using size metrics becomes comparable to that of a random predictor).
Our study picks up from where this work left off by examining the important question:what is a good measure of effort in effort-aware models?Although LOC was used as a de facto measure,we would like to examine whether there exist other metrics that are better predictors of effort to use in effort-aware models,as hinted at by previous studies[22].
2.2.Effort estimation
There has been a healthy number of studies on effort estimation as well.Most of these studies examine the next-release problem: given a set of project parameters(e.g.,the number of available developers)how much effort will my next release require?Other work attempts to estimate the effort required to?x a bug.
2.2.1.Estimating effort of next release
A number of studies focuses on estimating the effort required for a future release in order to assist in project scheduling or exter-nal contract bidding[7,31,4,23].
These studies use metrics based on the features of past project releases(i.e.,functional size measures,manager’s skill level and software development environment)and project requirements (i.e.,how many developers and testers are available to work on the next release).For example,Shepperd and Scho?eld[31]pro-pose the Estimation by Analogy(EbA)technique that derives the effort from one or more past analogous projects that are similar to the current project.They show that EbA outperforms other esti-mation methods that use linear regression.
2.2.2.Estimating the time to?x a bug
Other studies related to effort estimation focus on estimating the time it takes to?x a bug[1,12,18,34,36].Song et al.[34]uses associ-ation rule mining to estimate the effort required to?x a bug.They use bug type data(e.g.,whether the bug concerns an initialization error or an interface error)to predict the effort required to?x the bug.Wei?et al.[36]use the text in the title and description?elds of an issue report to predict the effort required to address the issue. Giger et al.[12]and Hewett and Kijsanayothin[18]estimate the time to?x a bug based on metrics extracted from the bug report itself (e.g.,the reporter’s name and the bug severity and priority).More re-cently,Ahsan et al.[1]analyze the correlation between the time it takes to address an issue and source code metrics(e.g.,LOC and Cyc-lomatic complexity).They?nd low correlation values for LOC and Cyclomatic complexity for the Mozilla project.
There are some key differences between the prior work on ef-fort estimation and our work.First,our goal is not to estimate the time it takes to?x a bug,rather our goal is to determine what is a good measure of the effort for use in effort-aware models.Second,
1Our data is available at:http://posl.ait.kyushu-u.ac.jp/$kamei/publications/data/
IST2013.zip.
1982 E.Shihab et al./Information and Software Technology55(2013)1981–1993
we map and perform our effort analysis to the?le level,not the is-sue or bug level.We map effort to the?le level in order to use and investigate the impact of our?ndings on previous bug prediction work(which is mostly performed at the?le level),which we exam-ine in more detail in Section5.
Third,one very important strength of our work is the used data set.The majority of the previous studies use the time between when a bug was opening until its closure as a measure of effort. These effort values are noisy since they may contain the off-time, where a developer is busy on other tasks or interrupted by other unrelated issues.In contrast,our effort data is input by the actual practitioner who made the change and considers the effort spent only on addressing the speci?c issue.Wei?et al.[36]used explicit effort data but they only consider one of the projects we consider, and in contrast,predict the time to?x a bug.
3.Methodology
Fig.1provides an overview of our approach,which we detail in this section.In a nutshell,we?rst extract issues that have effort re-cords from the JIRA issues database.These issues are parsed and the changed?les,their churn(i.e.,lines added and deleted) and the effort associated with the issues is recorded.Then,we ex-tract the source code of the changed?les for each issue and analyze the source code to extract various code(i.e.,complexity and size) and process(i.e.,churn)metrics.We map all of the metrics to the?le level and use this information to examine the correlations with,and predict effort.
3.1.JIRA issues database
JIRA is a popular issue tracking system.In addition to having the standard features of an issue tracking system(e.g.,recording bug descriptions,states and open/closure dates),JIRA has a very unique feature that enables users to input the value of effort that an issue takes to address.
The?rst step of our work was to extract these issues from the JIRA databases of four Java projects:Hibernate,JBoss,Mule and Spring.The main reason for choosing to use these projects is the fact that they used JIRA as their issue tracking system and they re-corded effort for their issues.
3.2.Extract issues
Similar to previous studies[36],we focused on issues that had a non-empty effort?eld,had a type?eld as Bug,Defect,New Feature,
Table1shows the number of used issues and?les from each project in our study.We note that only a small number of issues contains effort information and an even smaller number meets all of our criteria to be considered in the study.
At?rst glance,the number of issues in our data set seems to be low.However,our data set contains approximately double the amount of issues compared to the study by Wei?et al.[36](which uses567issues).To the best of our knowledge,that study is con-sidered the state of the art study for this kind of data.In addition, our data set covers four different projects,whereas Wei?et al.lev-eraged data from only one project.
3.3.Extract changed?les,process metrics and effort
After downloading all of the issues in html format,we wrote scripts that parsed all of the downloaded issues to determine the following:(1)the names of those?les that were changed to ad-dress the issue,(2)the process metrics(i.e.,the number of churned lines)for each?le and(3)the amount of effort required to address the issue.
The effort value extracted from the issues is logged by the per-son who addressed the issue.The effort value is measured in time and includes the time needed to perform all activities that the practitioner needed to complete the assigned issue.It includes the time needed to identify which?les need to be changed,the time it took to inspect these?les and decide where to make the changes and the time it took to make the actual changes.Having explicit effort data makes using this effort value ideal for our study, especially since this data is free of noise(i.e.,it does not include things such as triage time and testing delays).
At the end of this step,we have a linkage between the effort an issue required,?les changed to address the issue and the amount of churn done to these?les.
3.4.Extract source code and code metrics
To obtain code metrics(e.g.,code complexity metrics),we re-quire the source code of the changed?les.We use the list of?le names and corresponding revision numbers in each issue to down-load the corresponding revisions of?les from the source control database.
We use the Understand2.0[30]tool to analyze each?le and extract their code metrics(i.e.,complexity and size).Table2lists all of the metrics used in our study.A total of47complexity met-rics and26size metrics were extracted for each?les.In addition,
Fig.1.Approach overview.
E.Shihab et al./Information and Software Technology55(2013)1981–19931983
Table1
Number of issues in each project.
Hibernate JBoss Mule Spring
#issues before2011–01-0110,66692,179654323,504 \Non-empty effort data24222201251852 \Type:Bug,Defect,New Feature,Feature Request,Task,Sub-task,Improvement,Patch24121781251833 \Status:Closed,Resolved23121311221713 \Resolution:Done,Fixed,Complete22519791131496 \Priority:not Trivial21819661131025 \Total issues that modify source code17150640297 Total number of?les114714212861409
Table2
Summary of metrics.
Dim.ID Name De?nition Level
Complexity LOC Total Lines of Code The total number of lines File CDEN Cyclomatic Complexity
Density
The density of cyclomatic complexity(VG_sum/LOC)
CODEN Comment Density The density of comments(TCOLOC/LOC)
CC Cyclomatic Complexity The cyclomatic complexity for all nested functions or methods.Three measures are provided for CC:avg,
max and total
File
CCM Cyclomatic Complexity
Modi?ed The modi?ed cyclomatic complexity for all nested functions or methods.The CCM expects that a multi-decision structure statement(e.g.,switch)is counted as1.Three measures are provided for CCM:avg, max and total
CCS Cyclomatic Complexity
Strict The strict cyclomatic complexity for all nested functions or methods.The CCS expects that logical conjunction and conditional expressions add1to the complexity for each of their occurrences.Three measures are provided for CCS:avg,max and total
CCE Cyclomatic Complexity
Essential The essential cyclomatic complexity for all nested functions or methods.The CCE iteratively replaces all structured programming primitives to a single statement,then calculates CC.Three measures are provided for CCE:avg,max and total
CBO Coupling Between
Objects The number of other classes to which this class is coupled.Three measures are provided for CBO:avg,
max and total
Class
NOC Number Of Children The number of immediate subclasses.Three measures are provided for NOC:avg,max and total
RFC Response For a Class The number of methods,including inherited ones.Three measures are provided for RFC:avg,max and
total
DIT Depth of Inheritance
Tree The depth of a class within the inheritance hierarchy.Three measures are provided for DIT:avg,max and total
LCOM Lack of Cohesion in
Methods 100%–average cohesion for class data members.Three measures are provided for LCOM:avg,max and total
WMC Weighted Methods per
Class
The number of weighted methods per class.Three measures are provided for WMC:avg,max and total
FOUT Fan out The number of method calls.Three measures are provided for FOUT:avg,max and total Method NBD Nested Block Depth The nested block depth of the methods.Three measures are provided for NBD:avg,max and total
PAR Number of Parameters The number of parameters of the methods.Three measures are provided for PAR:avg,max and total
VG McCabe Cyclomatic
Complexity The McCabe cyclomatic complexity of the methods in a?le.Three measures are provided for VG:avg, max and total
Size TBLOC Total Blank Lines of
Code
The number of blank lines File
TCLOC Total Code Lines of Code The number of lines that contain source code
TCOLOC Total Comment Lines of
Code
The number of lines that contain comments
TNOS Total Number of
Semicolons
The number of semicolons
TNOST Total Number of
Statements
The number of declarative or executable statements
TNODST Total Number of
Declarative Statements
The number of declarative statements
TNOEST Total Number of
Executable Statements
The number of executable statements
TNOT Total Number of Classes The number of classes
TNOM Total Number of
Methods
The number of methods
NOF Number of Fields The number of?elds of the classes.Three measures are provided for NOF:avg,max and total Class
NOM Number of Methods The number of methods of the classes.Three measures are provided for NOM:avg,max and total
NSF Number of Static Fields The number of static?elds of the classes.Three measures are provided for NSF:avg,max and total
NSM Number of Static
Methods
The number of static methods of the classes.Three measures are provided for NSM:avg,max and total MLOC Method Lines of Code The number of method lines of code.Three measures are provided for MLOC:avg,max and total Method Churn CHURN Total Churn The sum of the number of added lines of code and the number of deleted lines of code File ADD Total Added Lines The number of lines of code added to a?le
DEL Total Deleted Lines The number of lines of code deleted in a?le
1984 E.Shihab et al./Information and Software Technology55(2013)1981–1993
code and process metrics and effort(e.g.,the more complex a piece of code is,the more effort it requires to be addressed).
3.5.Map metrics and effort to?les
The effort in the issue tracking system is recorded at the issue level.As mentioned earlier,we map effort to the?le level,not the issue level in order to study the relationship between the var-ious code and process metrics and to compare our?ndings to pre-vious bug prediction work,which are performed at the?le level. Since issues may touch one or more?les,we need to map the issue effort to the?le level.
3.5.1.Mapping effort to?les
We can employ a number of strategies when transforming the effort from the issue to the?le level.For example,we can take the average effort of all the issues that touch a?le and assign it to the?le.However,we decided to assign the effort value of a?le to be the maximum effort required to change it in all of the issues that touch the?le.There are two main reasons for this choice.First, assigning the maximum effort of all the issues that touch a?le is considered to be the worst-case scenario(i.e.,the highest possible effort)for that?le.Therefore,using the maximum value is seen as a conservative approximation.Second,we experimented with mapping the average,median and minimum effort of all the issues to the?le level.However,using maximum effort yielded the best and most meaningful correlations with effort.For example,in Ta-ble5we show the correlations of the different metrics with aver-age effort,whereas in Table6we show the correlations of the different metrics with using maximum effort.Clearly,using maxi-mum effort yields higher correlation values.
To illustrate how we perform the mapping,we use the follow-ing example.Suppose we have two issues Issue1and Issue2that took3600and1800s,respectively.Issue1requires?les fileA and fileB be modi?ed,while Issue2requires that fileA and fileC to be modi?ed.Then we calculate the effort for fileA as the maximum of Issue1and Issue2,which is3600s(Issue1), the effort for fileB is3600s(Issue1)and the effort for fileC is1800s(Issue2).
3.5.2.Mapping metrics to?les
Similar to the issues,we also need to map the metrics to the?le level,i.e.,make each?le one data point.Since some?les may be touched by multiple issues(and therefore have multiple revisions), we assigned each?le its average value of the metrics.For example,if the Cyclomatic Complexity(CC)of a fileA is50in Issue1and100
in Issue2,then we would assign a CC value ofe50t100
2?75Tto
fileA.
4.Data exploration
To the best of our knowledge,this is one of the?rst(in addition to the study by Wei?et al.[36])studies to leverage explicit effort data.Therefore,before delving into our case study results,we?rst explore our effort data in more detail.
We examine the distribution of the effort data at the issue and ?le levels.We report a few of the most common descriptive statis-tics,i.e.,mean,min,max,standard deviation(SD)for all projects. To study the skewness of the data,we calculate the skew and kur-tosis measures.
Skew measures the amount of asymmetry in the probability distribution of a variable,in relation to the normal distribution.Po-sitive skew means that the distribution of the metric values are mostly on the low end of the scale,while negative skew indicates that most of the metric values are on the high end of the scale.The normal distribution has a skew value of0.
Kurtosis on the other hand characterizes the relative peaked-ness or?atness of a distribution,in relation to the normal distribu-tion.Positive kurtosis indicates that a curve is too tall and negative kurtosis indicates a curve that is too?at.A normal distribution has
a kurtosis value of0.
4.1.Issue level exploration
Table3shows the descriptive statistics for the extracted issues of the Hibernate,JBoss,Mule and Spring projects.From the table, we observe that the average effort required to address an issue is between4–5h for the Hibernate,Mule and Spring projects.The JBoss project,however,has a much higher average effort per issue, approximately12h.One possible explanation for the high mean effort value is the fact that JBoss had the most number of issues and?les,therefore,it had more outliers.In fact,the high kurtosis value for JBoss indicates that.
Additionally,the Skew and Kurtosis values for the Hibernate, JBoss and Spring projects are well over0(meaning the distribution of the data is far from normally distributed).The effort data for Mule is less skewed.
To get a better idea of the skewness in the distributions,we plot the effort data at the issue level in Fig.2.Clearly,we see that the majority of the issue effort values are on the lower end of the scale for the Hibernate,JBoss and Spring projects.Mule seems to have a small jump in the number of issues at approximately12h.We examined the issues that had this value of effort and found that these issues had required large changes to many?les(more than 10?les were modi?ed to address these issues).Furthermore,we would like to note that since we did not have many issues for the Mule project,its data was very sensitive to anomalies.
4.2.File level exploration
We also explore the distribution of the data at the?le level(Ta-ble4).We see that the average effort per?le is higher than that per issue.The main reason for this is the fact that when we map the effort from the issue level to the?le level,we assign the?le the maximum effort of all the issues that touched it.
The distribution at the?le level seems to be skewed for the Hibernate and the JBoss projects as well.However,for Mule and Spring,the skew and kurtosis values are relatively small.This can be con?rmed from Fig.3,which plots the distribution of effort at the?le level for all four projects.Once again,we see a spike in the number of?les that have an effort of approximately12h in the Mule project.After manual inspection of the?les with that effort value,we found that once again,these?les were the ones changed by the large issues mentioned earlier.
5.Case study results
This section discusses our three research questions.First,we examine the correlations between the various metrics and effort. Then,we determine which of LOC,code or process metrics best predicts effort.Finally,we study the implications of our?ndings on previous effort-aware bug prediction studies.
Table3
Change level effort(measured in hours).
Project Mean SD Min Max Skew Kurtosis
Hibernate 4.848.850.0278.00 4.4627.99 JBoss12.7121.950.00280.00 5.3147.78 Mule 4.74 4.440.0018.00 1.210.50
Spring 4.42 6.970.0844.00 3.1010.86
E.Shihab et al./Information and Software Technology55(2013)1981–19931985
5.1.RQ1.Does LOC correlate better with effort than other code and process metrics?
To examine the relationship between the various metrics and effort,we use
correlation analysis.Figs.4–7shows the Spearman correlation of all extracted metrics with effort for the Hibernate,JBoss,Mule and Spring projects,respectively.
In addition,Table 6presents the correlation values and their statistical signi?cance based on their p -values.The absolute improvement over LOC is shown in brackets,under the Improv.column.Due to the large number of metrics,we only show the cor-relation between the best performing metrics from each category (i.e.,LOC,complexity,size and churn)and effort.For example,for the Hibernate project,the CBO_max metric is the complexity met-ric with the highest correlation with effort.The category of metrics that has the highest correlation with effort for each project is shaded in gray.We observe the following:
5.1.1.LOC has weak correlation with effort
We observe from Table 6that LOC does not have a high corre-lation with effort.The highest correlation is 0.13in the JBoss pro-ject.The correlation for the other projects is even lower and for the Mule project this correlation is practically zero.
https://www.doczj.com/doc/3b2258747.html,plexity metrics have a stronger correlation with effort than LOC
Table 6shows that complexity metrics have a stronger correla-tion with effort than LOC.In fact,complexity metrics have a stron-
ger correlation than size and churn metrics as well.However,we would like to note that the correlation of all of the metrics with ef-fort remains rather low.
5.1.3.Different metrics best correlate with effort for different projects Examining the metrics that best correlate with effort in Table 6,we observe that for almost each project,a different metric (in each category)best correlates with effort.Even though we ?nd that complexity metrics correlate best with effort,the speci?c metric depends on the project.
Although the measured correlations are not that strong,previ-ous work [33,29]showed that low correlations do not necessarily mean low prediction accuracy.Therefore,we now proceed to build prediction models for effort to investigate whether or not the code and process metrics (e.g.,complexity)are a better predictor of ef-fort than LOC.
5.2.RQ2.Is LOC a better predictors of effort than other code and process metrics?
5.2.1.Motivation
Thus far,we were able to establish that LOC does not have a high correlation with effort and that complexity metrics correlate better with effort.Now,we would like to examine which of LOC or the other code and process metrics best predict effort.
In addition,we would like to know how well code and process metrics predict effort for different projects.For example,we would like to know if there exists one category of metrics that performs well at predicting effort in all projects or whether each project has its own set of metrics that predict effort well.If we can ?nd one met-ric or category of metrics (e.g.,complexity)that outperforms the other categories of metrics in all projects,then we can recommend this category of metrics for future effort-aware studies.
5.2.2.Approach
To determine the best category of metrics to predict effort,we build linear regression models that aim to predict the effort
Table 4
File level effort (measured in hours).Project Mean SD Min Max Skew Kurtosis Hibernate 14.0718.200.0378.00 2.40 5.72JBoss 26.2835.700.03280.00 3.9323.32Mule 7.23 4.750.0018.000.23à1.24Spring
15.19
12.31
0.17
44.00
0.64
à0.65
1986 E.Shihab et al./Information and Software Technology 55(2013)1981–1993
required to address a ?le.The independent variables of the models are the set of metrics in each category (e.g.,churn)and the depen-dent variable is the effort required to address the ?le (measured in seconds).We use a linear regression model (rather than a logistic regression model,for example)since effort is a continuous vari-able,given in seconds.
To perform our analysis,we divide the data set into:a training set and a test set.The training set contains 90%of the entire data set and is used to train the linear regression model.The test set contains the remaining 10%of the data and is used to test the accu-racy of the model.We perform this random splitting 10times (i.e.,10-fold cross validation)and report the averages of the 10iterations.
Based on our analysis in Section 4that showed that the inde-
pendent variables and the dependent variable have high skew and kurtosis values,we log-transformed the variables to alleviate the effects of the high skew and kurtosis.Log-transformations are commonly employed in prediction work to deal with high skew and kurtosis [37,33].
We employ a backward elimination stepwise regression tech-nique to select only a relevant,non-redundant set of independent variables [27].In backward selection stepwise regression,an initial model is built using all independent variables.Then,the deletion of independent variables is tested and independent variables are re-moved from the model if they do not make a statically signi?cant contribution to the model.This process is repeated until the no fur-ther improvements are possible.Finally,the model will contain the best set of independent variables that achieve the highest variance explained.
Furthermore,to avoid problems due to multicollinearity [32],we computed the pairwise correlations of the independent vari-ables and removed any independent variable that had an inter-cor-relation greater than 0.8.After performing the prediction,we evaluate the performance of the model using two complementary measures.First,we evaluate the predictive power of the model by calculating the Spearman correlation between the output of the model with the actual effort for each ?le.The explanative power of the model is evaluated by measuring the R 2value of the ?tted
model.These two measures are commonly used in previous work to evaluate the accuracy of prediction models [10].
5.2.3.Results
Table 8and Table 7show the predictive and explanative power of each model.Table 7uses Pearson correlation and Table 8uses Spearman correlation.In addition,we report the statistical signi?-cance of the correlations for each model.
In all four projects,prediction models built using complexity metrics outperformed the LOC models in terms of predictive and explanative power (shown in gray in the table).We would like to point out here that although the prediction models using complex-ity metrics were the best performing,their overall predictive and explanative power are still low.We discuss this issue in more de-tail in Section 6.
We also built a model that contained metrics from all catego-ries,labeled ‘‘All’’in Table 8and Table 7.To assure that only the signi?cant metrics are used,we performed the same stepwise regression technique mentioned above to prune the ‘‘All’’model as well.The ‘‘All’’model seems to provide the best performance,providing a signi?cant improvement over the LOC model and a slight improvement over the complexity model in all four projects.This ?nding shows that although complexity metrics outperform LOC,using all metrics is the best option when predicting https://www.doczj.com/doc/3b2258747.html,plexity metrics are better predictors of effort than LOC,churn and size metrics.However,combining LOC,complexity,churn and size metrics provides the best prediction of effort.
5.3.RQ3.How do our ?ndings impact prior effort-aware bug prediction ?ndings?
5.3.1.Motivation
In the previous research question,we found that using com-plexity metrics is a better predictor of effort than using LOC alone,however,using all metrics is the best predictor of effort.Now we would like to investigate the impact of the aforementioned
E.Shihab et al./Information and Software Technology 55(2013)1981–19931987
1988 E.Shihab et al./Information and Software Technology55(2013)1981–1993
?ndings on the prior work on effort-aware models.Generally
speaking,effort-aware models serve two purposes.First,they as-sist in ranking which ?les to address ?rst.Second,they provide practitioners with an estimate of the effort (e.g.,hours)required to address the selected ?les.
E.Shihab et al./Information and Software Technology 55(2013)1981–19931989
Therefore,we use the data set from the study done by Kamei et al.[19]to see whether using LOC signi?cantly impacts the?nd-ings of their study based on the two above mentioned criteria,?le-ranking and effort-estimation.
5.3.2.Approach
In their work,Kamei et al.[19]built bug prediction models to predict the number of bugs in a?le.Then,the?les are prioritized based on their risk values,which is measured as Risk LOC?#Bugs. The main idea behind this is that?les with the most bugs and least effort(measured in LOC)would be prioritized higher.5.3.3.File-ranking
To examine the impact on the study by Kamei et al.[19]in terms of?le rankings,we generated three lists of?les that are ranked based on their risk.One list used LOC as a measure of effort in the risk equation,another list used complexity metrics and the third list used all of the metrics.Then,we use the Spearman rank correlation to measure the similarity between the three lists.
5.3.4.Effort-estimation
Since we showed that using complexity or all metrics is a better measure of effort,we would like to know if using LOC over-or un-der estimated the amount of effort,compared to when complexity
Table7
(Pearson)Effort prediction results.
Project Category Average predictive power
(correlations)Average explanative power(R2)
Hibernate LOC0.11???0.00 Complexity0.22???0.08
Size0.020.00
Churnà0.11???0.00
All0.26???0.10
JBoss LOC0.05?0.00 Complexity0.30???0.13
Size0.13???0.05
Churn0.17???0.03
All0.35???0.17
Mule LOCà0.20???0.00 Complexity0.30???0.11
Size0.050.01
Churnà0.25???0.00
All0.29???0.12
Spring LOC0.06??0.00 Complexity0.28???0.10
Size0.24???0.09
Churn s0.22???0.07
All0.39???0.19
?p<0.1.
??p<0.05.
???p<0.01.Table8
(Spearman)Effort prediction results.
Project Category Average predictive power
(correlations)
Average explanative
power(R2) Hibernate LOC0.100.00
Complexity0.20??0.08
Size0.050.00
Churnà0.050.00
All0.27???0.10 JBoss LOC0.020.00
Complexity0.31???0.13
Size0.15?0.05
Churn0.19??0.03
All0.36???0.17 Mule LOCà0.200.00
Complexity0.300.11
Size0.040.01
Churnà0.200.00
All0.280.12 Spring LOC0.050.00
Complexity0.29???0.10
Size0.26???0.09
Churn0.25???0.07
All0.41???0.19
?p<0.1.
??p<0.05.
???p<0.01.
Table5
Metric correlations with effort(using average effort).
Complexity Size Churn
LOC Metric Corr.Improv.Metric Corr.Improv.Metric Corr.Improv.
Hibernateà0.07??CCE_ave0.05(+169%)TNOT0.00(+107%)DELà0.07??(à4%) JBossà0.06??CBO_ave0.14???(+354%)TCOLOC0.04(+168%)CHURN0.14???(+344%) Muleà0.08NOC_max0.07(+186%)NOF_max0.02(+124%)ADD0.08(+200%) Springà0.07???DIT_max0.10???(+237%)MLOC_ave0.08???(+209%)DEL0.15???(+314%)
?p<0.1.
??p<0.05.
???p<0.01.
Table6
Metric correlations with effort(using maximum effort).
Complexity Size Churn
LOC Metric Corr.Improv.Metric Corr.Improv.Metric Corr.Improv.
Hibernate0.04CDEN0.19???(+395%)MLOC_total0.10???(+154%)DELà0.04(à193%) JBoss0.02CBO_ave0.23???(+1019%)TCOLOC0.11???(+415%)CHURN0.16???(+688%) Muleà0.03DIT_max0.16???(+720%)MLOC_total0.07(+356%)ADD0.05(+290%) Spring0.06??DIT_max0.33???(+412%)MLOC_ave0.30???(+358%)DEL0.30???(+362%)
?p<0.1.
??p<0.05.
???p<0.01.
1990 E.Shihab et al./Information and Software Technology55(2013)1981–1993
or all metrics are used.The way we measure this is we generate a list of?les using the Risk LOC equation.Then,we measure the amount of effort required to address this list of?les when LOC is used,when complexity metrics are used and then all metrics are used as a measure for effort.Finally,we compare the difference in effort for the generated lists of?les.
To perform the comparison,we need to?rst estimate effort(in seconds)from LOC,complexity and all metrics.Because we do not have explicit effort data for Kamei’s data set,we estimate effort data using the best performing prediction models from our effort prediction analysis,as shown in Table8.For LOC,we use the model from the Hibernate project.For complexity,we use the model from the JBoss project and for all metrics we use the model from the Spring project.
Performing the aforementioned steps allows us to compare LOC, complexity and all metrics,in terms of effort,on a level playing ?eld.
5.3.5.Results
File-ranking.Table9shows the correlation coef?cients between the ranked lists generated using LOC,complexity and all metrics for the JDT,PDE and Platform https://www.doczj.com/doc/3b2258747.html,ing complexity as a mea-sure of effort signi?cantly affects the results of Kamei’s study since the lists generated using complexity have a negative weak correla-tion with the?le list using LOC(which was used as a measure of effort by Kamei et al.)for all three projects.On the other hand, the lists generated using LOC have a positive,strong correlation with the?le list generated using all metrics,which proved to be the best predictor of effort(as shown in Table8).
The strong correlation between LOC and all is encouraging since it shows that although LOC was not a good predictor of effort,its use in effort-aware bug prediction models is valid.For the purpose of?le ranking,using LOC as a measure of effort performs similar to our best effort predictor,the all metrics model.
5.3.
6.Effort-estimation
Fig.8shows the estimated effort required versus the percentage of bugs.The three lines show the effort estimate when LOC,com-to a different result in terms of effort-estimation.In other words, our?ndings show that if someone is interested in the effort-aware ranking of?les,using effort-aware prediction models,then using LOC is?ne.However,if someone is interested in approximating the amount of effort that needs to be spent on these?les(e.g.,to address these bugs),then LOC is not a good measure since it seems to underestimate this effort.
For the purpose of ranking the most risky?les,using LOC as a mea-sure of effort performs similar to our best effort predictor.However, for the purpose of effort-estimation,using LOC under-estimates the amount of effort required compared to our best effort predictor.
6.Discussion
Studying what is a good measure of effort is a very important is-sue,since recent research shows that effort needs to be taken into ac-count for bug prediction to become more practical[22].However, there is a lack of empirical evidence of how to best measure effort. This is mainly due to the lack of availability of explicit effort data.
This study is a step in the right direction,however,it is certainly far from perfect.For this reason,we plan to(and encourage other researchers to)expand on this work in the future.To facilitate fu-ture studies,we are making our data publicly available to the re-search community through the PROMISE repository.In particular, we see three directions for immediate improvement:
6.1.Collecting better quality effort data
The four projects used in our study are some of the?rst to re-cord effort data.However,as we can see from Table1,most pro-jects have a very small percentage of issues with non-empty effort data.Having such little data is a major obstacle that our com-munity needs to overcome in order to conduct large-scale research. We hope that this study will inspire future developers to carefully input effort data that can be used for future studies.
We plan to revisit our study when more,better quality data is made available.At the same time,we are attempting to obtain such data from commercial projects,who may keep better track of ex-plicit effort data.
Table9
Correlations of top20%most risky?les lists when LOC,complexity and all metrics are used as a measure for effort.
Fig.8.JDT.
E.Shihab et al./Information and Software Technology55(2013)1981–19931991
6.2.Improving prediction accuracy
Although our experiments showed that using complexity and all metrics had a higher correlation and could better predict effort than LOC,we believe there is still room for improvement.We believe the prediction accuracy could be improved by obtaining more and better quality data and by exploring more categories of metrics.For example,it may be helpful to include code ownership metrics[6]in addition to the code complexity metrics,since it may take less effort to change complex code by a person who owns the code versus a person who is new to the same piece of complex code.
In addition,we plan to explore the use of different prediction techniques such as regression trees or random forest.
7.Threats to validity
7.1.Threats to construct validity
consider the relationship between theory and observation,in case the measured variables do not measure the actual variable.
The collected effort data is input by the developer who made the change.In certain cases,the input data may not re?ect the ac-tual effort(e.g.,this data maybe misrepresented or in?ated due to speci?c motivations)required to change the?le.Also,only about 10%of the reports had an non-empty effort?eld.This scarcity of the data may impact some of our?ndings or the quality of our models.That said,as mentioned earlier our data set contains approximately double the amount issues compared to prior state-of-the-art work(i.e.,Wei?et al.[36]).
Furthermore,we map effort from the issue level to the?le level by setting each?le’s effort as the maximum effort(from all the is-sues that touched the?le)out of the all issues that touch it.In some cases(e.g.,when the?x is very easy),using the maximum va-lue might not be representative.However,we chose to be conser-vative and used the maximum effort value in order to consider the worst case scenario.
When studying the impact of our?ndings on prior work,we use the coef?cients from the best model of the projects we have effort data for(i.e.,Hibernate,JBoss,Mule and Spring)to map LOC and complexity to effort measured in seconds for the JDT,PDE and Plat-form projects.Ideally,we should use the coef?cient from the pro-ject itself to do this mapping.However,we do not have effort data for the JDT,PDE and Platform projects.
As shown in Table1,a very small number of issues contain ef-fort data.Having such a small percentage to conduct our studies may affect our?ndings,however,we would like to note that this type of data is very rarely available.Also,our study uses approxi-mately double the amount of issues compared to the state of the art to using such data.Therefore,we see this study as a starting point and plan to continue to mine such data as it becomes more widely available.
7.2.Threats to external validity
considers the generalization of our?ndings.All of the four pro-jects used are open source projects written in Java,therefore,our results may not generalize to other open source or commercial pro-jects written in other programming languages.
When revisiting the prior effort-aware bug prediction results, we found that using LOC as a measure for effort under-estimates effort,compared to when complexity is used.Although we ob-served the same phenomena in all three projects,the same trend might not generalize to other project.
When evaluating the relationship of the different metrics with effort,we used Spearman’s rank correlation and the R2measures. Traditionally,effort estimation work uses measures such as the Mean Magnitude of Relative Error(MMRE)since its primary goal is to measure how accurate an effort estimation is[38].In our case however,our primary goal was to measure the relationship of the metrics with effort,hence using correlations and the R2measures are a better?t for our analysis.
8.Conclusions
Recent work stressed the importance of considering effort in bug prediction models.Most of these studies used LOC as the de facto measure of effort.In this paper,we set out to empirically examine which of LOC,or other code and process metrics are the best measures of effort.Through a study on four open source pro-jects,we found that complexity measures have the highest correla-tion with effort.Furthermore,we also found that using a combination of LOC,code and complexity metrics provides a better prediction of effort than using LOC alone.
Replication of the work by Kamei et al.[19]shows that using LOC in effort-aware bug prediction models provides results that are similar to using all metrics when prioritizing the most risky ?les.However,for the purpose of effort-estimation,using LOC un-der-estimates the amount of effort required compared to our best effort predictor.
References
[1]S.N.Ahsan,J.Ferzund,F.Wotawa,Program?le bug?x effort estimation using
machine learning methods for OSS,in:Proc.Int’l Conf on Software Engineering &Knowledge Engineering(SEKE’09),2009,pp.129–134.
[2]E.Arisholm,L.C.Briand,Predicting fault-prone components in a java legacy
system,in:Proc.Int’l Symposium on Empirical Software Engineering (ISESE’06),2006,pp.8–17.
[3]E.Arisholm,L.C.Briand,E.B.Johannessen,A systematic and comprehensive
investigation of methods to build and evaluate fault prediction models,J.Syst.
Softw.83(1)(2010)2–17.
[4]M.Auer,A.Trendowicz,B.Graser,E.Haunschmid,S.Bif?,Optimal project
feature weights in analogy-based cost estimation:Improvement and limitations,IEEE Trans.Softw.Eng.32(2)(2006)83–92.
[5]V.R.Basili,L.C.Briand,W.L.Melo,A validation of object-oriented design
metrics as quality indicators,IEEE Trans.Softw.Eng.22(10)(1996)751–761.
[6]C.Bird,N.Nagappan,H.Gall,P.Devanbu,B.Murphy,An Analysis of the Effect
of Code Ownership on Software Quality Across Windows,Eclipse,and Firefox.
Technical Report MSR-TR-2010-140,Microsoft Research,2010.
[7]B.W.Boehm,Software Engineering Economics,?rst ed.,Prentice Hall PTR,
Upper Saddle River,NJ,USA,1981.
[8]L.C.Briand,J.W.Daly,J.K.Wüst,A uni?ed framework for coupling
measurement in object-oriented systems,IEEE Trans.Softw.Eng.25(1) (1999)91–121.
[9]S.R.Chidamber,C.F.Kemerer,A metrics suite for object oriented design,IEEE
Trans.Softw.Eng.20(6)(1934)476–493.
[10]M.D’Ambros,https://www.doczj.com/doc/3b2258747.html,nza,R.Robbes,An extensive comparison of bug prediction
approaches,in:Proc.Int’l Working Conf.on Mining Software Repositories (MSR’10),2010,pp.31–41.
[11]K.E.Emam,W.Melo,J.C.Machado,The prediction of faulty classes using
object-oriented design metrics,J.Syst.Softw.56(1)(2001)63–75.
[12]E.Giger,M.Pinzger,H.Gall,Predicting the?x time of bugs,in:Proc.Int’l
Workshop on Recommendation Systems for Software Engineering(RSSE’10), 2010,pp.52–56.
[13]M.W.Godfrey,A.E.Hassan,J.Herbsleb,G.C.Murphy,M.Robillard,P.Devanbu,
A.Mockus, D.E.Perry, D.Notkin,Future of mining software archives:a
roundtable,IEEE Softw.26(1)(2009)67–70.
[14]T.L.Graves, A.F.Karr,J.S.Marron,H.Siy,Predicting fault incidence using
software change history,IEEE Trans.Softw.Eng.26(7)(2000)653–661. [15]T.Gyimothy,R.Ferenc,I.Siket,Empirical validation of object-oriented metrics
on open source software for fault prediction,IEEE Trans.Softw.Eng.31(10) (2005)897–910.
[16]A.Hassan,The road ahead for mining software repositories,in:Frontiers of
Software Maintenance(FoSM’08),2008,pp.48–57.
[17]A.E.Hassan,Predicting faults using the complexity of code changes,in:Proc.
Int’l Conf.on Softw.Eng.(ICSE’09),2009,pp.78–88.
[18]R.Hewett,P.Kijsanayothin,On modeling software defect repair time,
Empirical Softw.Eng.14(2)(2009)165–186.
1992 E.Shihab et al./Information and Software Technology55(2013)1981–1993
[19]Y.Kamei,S.Matsumoto,A.Monden,K.Matsumoto,B.Adams,A.E.Hassan,
Revisiting common bug prediction?ndings using effort aware models,in: Proc.Int’l Conf.on Software Maintenance(ICSM’10),2010,pp.1–10.
[20]T.M.Khoshgoftaar, E.B.Allen,W.D.Jones,J.P.Hudepohl,Data mining for
predictors of software quality,Int.J.Softw.Eng.Knowledge Eng.9(5)(1999) 547–564.
[21]T.J.McCabe,A complexity measure,in:Proc.Int’l Conf.on Softw.Eng.
(ICSE’76),1976,p.407.
[22]T.Mende,R.Koschke,Revisiting the evaluation of defect prediction models,in:
Proc.Int’l Conf.on Predictor Models in Software Engineering(PROMISE’09), 2009,pp.7:1–7:10.
[23]T.Menzies,O.Jalali,J.Hihn,D.Baker,K.Lum,Stable rankings for different
effort models,Autom.Softw.Eng.17(4)(2010)409–437.
[24]T.Menzies,https://www.doczj.com/doc/3b2258747.html,ton,B.Turhan,B.Cukic,Y.Jiang,A.Bener,Defect prediction
from static code features:current results,limitations,new approaches,Autom.
Softw.Eng.17(4)(2010)375–407.
[25]R.Moser,W.Pedrycz,G.Succi,A comparative analysis of the ef?ciency of
change metrics and static code attributes for defect prediction,in:Proc.Int’l Conf.on Softw.Eng.(ICSE’08),2008,pp.181–190.
[26]N.Nagappan,T.Ball,Use of relative code churn measures to predict system
defect density,in:Proc.Int’l Conf.on Softw.Eng.(ICSE’05),2005,pp.284–292.
[27]N.Nagappan,T.Ball,Use of relative code churn measures to predict system
defect density,in:Proc.Int’l Conf.on Softw.Eng.(ICSE’05),2005,pp.284–292.
[28]N.Nagappan,T.Ball,A.Zeller,Mining metrics to predict component failures,
in:Proc.Int’l Conf.on Softw.Eng.(ICSE’06),2006,pp.452–461.[29]N.Ohlsson,H.Alberg,Predicting fault-prone software modules in telephone
switches,IEEE Trans.Softw.Eng.22(12)(1996)886–894.
[30]Scienti?c Toolworks,Inc.Understand2.6.
[31]M.Shepperd,C.Scho?eld,Estimating software project effort using analogies,
IEEE Trans.Softw.Eng.23(11)(1997)736–743.
[32]E.Shihab,Z.M.Jiang,W.M.Ibrahim,B.Adams,A.E.Hassan,Understanding the
impact of code and process metrics on post-release defects:a case study on the Eclipse project,in:Proc.Int’l Symposium on Empirical Softw.Eng.and Measurement(ESEM’10),2010,pp.1–10.
[33]Y.Shin,R.Bell,T.Ostrand,E.Weyuker,Does calling structure information
improve the accuracy of fault prediction?in:Proc.Int’l Working Conf.on Mining Software Repositories(MSR’09),2009,pp.61–70.
[34]Q.Song,M.Shepperd,M.Cartwright,C.Mair,Software defect association
mining and defect correction effort prediction,IEEE Trans.Softw.Eng.32(2) (2006)69–82.
[35]R.Subramanyam,M.S.Krishnan,Empirical analysis of ck metrics for object-
oriented design complexity:implications for software defects,IEEE Trans.
Softw.Eng.29(4)(2003)297–310.
[36]C.Wei?,R.Premraj,T.Zimmermann,A.Zeller,How long will it take to?x this
bug?in:Proc.Int’l Working Conf.on Mining Software Repositories(MSR’07), 2007,pp.1–8.
[37]T.Zimmermann,R.Premraj,A.Zeller,Predicting defects for Eclipse,in:Proc.
Int’l Workshop on Predictor Models in Software Engineering(PROMISE’07), 2007,pp.1–7.
[38]M.Shepperd,M.Cartwright,G.Kadoda,On building prediction systems for
software engineers,Empirical Softw.Eng.5(3)(2000)175–182.
E.Shihab et al./Information and Software Technology55(2013)1981–19931993
帮妈妈做家务500字作文五篇 妈妈平时为家操劳，我们可以帮妈妈做点家务减轻她的负担。下面是橙子为您带来的是帮妈妈做家务感受作文，希望对您有所帮助。 篇一：帮妈妈做家务今天妈妈下班非常早，下午下课了她把我接上后对我说：“贞贞，今天妈妈回家给你做好吃的。”我迫不及待的问妈妈：“什么好吃的呀？”“回家你就知道了，但是，你必须先把作业做完以后才能吃，否则不许吃饭，好吗？” 我为了吃上好吃的，到家以后我就赶快把作业拿出来，做了起来。妈妈就在厨房里忙起来了。 等我把作业做完以后，到厨房一看，妈妈正在和面，她看到我以后对我说：贞贞快来帮忙。然后就把厨房里的围裙拿了出来，给我围上了。“做什么？妈妈。”今天妈妈给你做豆沙包吃，好不好？我一听，高兴地蹦了起来，因为我最爱吃豆沙包了。你把这个大盆端到客厅去，用筷子把盆里的陷搅一搅，一定要把陷搅匀呀！知道了吗。 经过我和妈妈的努力不一会儿就把豆沙包包好了，然后我们就把包好的豆沙包放进了微波炉里，定好时间。哎呀！就等香喷喷的豆沙包出炉了。这时候再看我们俩个人，手上、身上、脸上及头上全都是白面粉，简直就成了一个小雪人了。我和妈妈都笑了。 时间过得好慢啊！等啊等啊，终于香喷喷的豆沙包就要出炉了。妈妈打开微波炉，把豆沙包拿了出来，可是一看，我们做的豆沙包和
市场上买的不一样呀！因为市场买的是圆形的，可是我们做的却是扁扁的，这是怎么一回事儿呢？经过我们认认真真的分析以后，觉得问题应该出在面粉上，因为我们和面时放水太多了，面软了，在烤制的过程中就变成扁扁的了。虽然形状不好看，但是吃起来还是蛮好吃的吗！毕竟这是我们的劳动成果呀！ 希望小朋友们都要帮妈妈多做点家务，给妈妈减轻点负担。这样我们才是一个好孩子。 篇二：帮妈妈做家务今天，妈妈在家大扫除，我看着妈妈一会整理房间，一会擦桌子，忙得上气不接下气，我见妈妈每天都这样忙忙碌碌的，得多吃亏损呀！于是，我产生了一个念头，如果我能帮妈妈分担一些家务活，妈妈就会不这么累了吗？ 于是，我二话不说，卷起袖子，拿起抹布和洗洁精，就开始擦玻璃了。我先将抹布打湿，拧干，再将洗洁精洒在玻璃上，又用湿毛巾将污点全部擦干净，最后，再用干毛巾将洗洁精擦干净，这样，一块洁净的玻璃就出来了。 接着，我拿出扫把，准备帮妈妈妇地。我将我平时乱丢乱放的玩具和零食，放回该放的位置后，我就用扫把仔仔细细、认认真真打扫一遍后，把垃圾扫入灰斗中，再倒入垃圾桶里，再将拉圾倒入垃圾堆中后，扫地任务也完成了。 我再拿来拖把，将地板拖得干干净净、一尘不染。 拖完地后，我拿几双脏兮兮的鞋子，开始洗鞋，我先将鞋子打湿，再将鞋子洒上泡沫，然后我拿出刷子来，将鞋子的里里外外、上上下
四年级谢谢你爸爸作文400字【六篇】【篇一】四年级谢谢你爸爸作文400字 俗话说：母爱如海，父爱如山，母的慈祥，父的严厉，合二为一就是爱，生活中有了爱才会更精彩。 记得国庆节放长假那几天，我感冒了，咳嗽的厉害，半夜里喘不过起来，爸爸妈妈说得赶快送医院，到了医院，医生说我得了急性气管炎，要挂盐水消炎。我听了，愣是吵：“不挂，不挂，我不挂盐水，我要回家，就是不挂。”爸爸火了，对我大吼：“叫你挂你就挂，少罗嗦。”我听了，很生气，心想：“天下哪有这样的爸爸，我生病了还那么凶。”委屈的泪水在眼眶中打转，无奈，只得向输液厅走去。 挂盐水时，我又难受又无聊，或许是药水关系，我想吐，爸爸在一边又给我漱口，又装盆子，还给我拍背。过了一会儿，我好点了。爸爸又说：“你平时不是最爱做手工吗，来，给我用报纸撕几个小动物吧!”我接过报纸，撕了许多，渐渐地也不觉得难受了，原来爸爸是为了让我分散注意力。不知不觉，我迷迷糊糊地睡着了。 天蒙蒙亮了，爸爸在我耳边轻声问：“小豪，饿了吧，你要吃点什么?”“小包子吧。”话音刚落，爸爸转身就走，不一会儿，热气腾腾的包子就端在了我的面前。我吃着包子，发现爸爸眼边有一圈黑黑的。我的视线又再一次模糊了。 这就是我的爸爸，严厉背后体现了对我无尽的关爱。爸爸，我一定好好学习来报答你。 【篇二】四年级谢谢你爸爸作文400字
打开门，好像就想睡了。同样是日光灯，家里却比琴室亮。我慢慢走到床边,躺下了，把眼闭上了。此时房间里一片寂静。 “懒虫，刚上完课不练怎么行！“爸爸大声的说话声把我吵醒了。“干什么，爸爸我困的不行，让我躺一会儿就马上起来练。““不行。”爸爸马上回了我的话。我生气了，爸爸也一样。爸爸的表情更加严肃了，大声的对我说：“你不去就出去，不要进来’’。我只认为自己是对的，于是对爸爸百般较辩平时爸爸总是护这我。我不明白今天他怎么了。我还和爸爸辩解没想到爸爸具然打了我。我的眼睛湿润了，觉的自己受了不该受的气，我更大声了还在为自己辩解着，爸爸气的涨红了脸又打了我好像有什么东西从我的鼻子里流出来，用手一摸竟然是血！我气极了便哭了起来。可是最后我还是练了琴。几个月后我还是忘了这事，我要考及了，我和一个朋友同时来到了考场。她先进去了，我从玻璃窗外看到了她失望的表情。她从考场走了出来，搭了搭我的肩说祝我好运便走了。我在这时十分紧张的走进考场考官对我说:“弹一首牛仔小镇吧！“这不是爸爸让我练的吗？我顺利过了官。我走出考场…… 这时只想找的爸爸对他说：“对不起爸爸，谢谢你！”【篇三】四年级谢谢你爸爸作文400字 从小，我们的父母就用他们的心血灌溉着我们。使我们来到这个美丽的世界，所以我们以后要报答我们的父母。 记得有一次，我的数学大作业本做了很多，后来被老师
小蜜蜂的作文100字 导读：篇一：小蜜蜂 一个阳光灿烂的早晨，小蜜蜂高高兴兴去采蜜。 他想：今天肯定花开得特别多特别美。没想到，刚刚飞过一个荷花池，突然，乌云密布，不一会儿，电闪雷鸣，雷声隆隆，大雨哗哗。小蜜蜂想：来不及回家，我得赶快找个避雨的地方。于是他马上躲在一片荷叶下。这把伞真不错。小蜜蜂一点儿都没有淋到雨。还好不久雨就停了。小蜜蜂大声说：“谢谢太阳公公!” 这个早晨他采的蜜比往日还多。 篇二：一只小蜜蜂 上语文课的.时候，一只小蜜蜂从窗外飞了进来，我想那只小蜜蜂可能是迷了路。蜜蜂在倪瑜跃的头上飞来飞去，好像把倪瑜跃像小花一样，他来采蜜了。 倪瑜跃和蜜蜂玩起了猫抓老鼠的游戏，张老师和同学们看到都笑了。 篇三：快乐的小蜜蜂 周末两天，我每天中午洗碗，擦桌子。 洗碗不难洗，先把碗用水冲一下，然后用海绵擦上洗洁精，最后用清水将泡沫冲干净，把碗翻过来抖一抖，放入盆里晾干。擦桌子也很方便，先用毛巾将桌子上的垃圾收集起来扔到垃圾桶里，冲一冲毛巾，再擦一遍桌子，将毛巾洗干净就可以了。 我好快乐啊，可以帮帮妈妈做家务。
篇四：一只小蜜蜂 上语文课的时候，嗡嗡嗡一只小蜜蜂从窗外飞了进来。只见那只小蜜蜂在倪瑜跃的头上飞来飞去，好像把倪瑜跃当成了小花一样。 倪瑜跃吓坏了，一个劲儿东躲西藏，和蜜蜂玩起了躲猫猫的游戏。他的动作引起了大家的注意。老师和同学们看到都笑了。 篇五：有趣的小蜜蜂 上课了，我们突然发现了一只小蜜蜂飞进了教室。李老师大喊一声：“看!”大家转头一瞧，发现了一只小蜜蜂在教室的窗上爬，不知它在干什么，可真有趣。我仔细地观察，发现它着急地趴在窗户上：“bzzzbzzz”的叫，我想，小蜜蜂在说：“我要飞回大自然，但我爬不出去，谁来帮帮我!”它爬了半天还是没有爬出去。最后，李老师说：“它一定能靠自己的本领爬出去的。” 不一会儿，小蜜蜂不见了，它终于爬出去了，飞回了大自然的怀抱中。 多么有趣的小蜜蜂啊! 有关小蜜蜂的作文100字 1.有关小蜜蜂的作文500字 2.有关写小蜜蜂的作文 3.有关小蜜蜂的作文 4.和小蜜蜂有关的作文 5.《小蜜蜂》作文 6.小蜜蜂的作文
小学四年级作文谢谢你【三篇】 导读：本文小学四年级作文谢谢你【三篇】，仅供参考，如果觉得很不错，欢迎点评和分享。 【篇一】 我的爸爸是一名南京陆军指挥学院的教授，有很多解放军叔叔都是他的学生。 我特别感谢他！ 感谢他陪我学习奥数。从二年级开始，我就参加了奥林匹克数学竞赛的学习。在学习中，遇到了许多困难。爸爸总是耐心地辅导，陪我一起做题，一起训练。经过两年的学习，我的进步很大，已经进入特强班了！ 感谢他陪我学习围棋。别看我年纪小，可是我已经算是围棋老手了。从幼儿园大班就开始学围棋。爸爸不但负责接送我，还担任陪练的任务。特别是今年打一段前，他每天都会和我下两盘。还好我没有让他失望哦！ 感谢他陪我学习魔方。为了教会我玩魔方，爸爸先上网学习，掌握了玩六面的本领以后，再来教我。刚开始学的时候，我老是出错。现在，已经“青出于蓝而胜于蓝”了。和爸爸比赛，我经常赢呢。 其实，除了这些，还有很多很多…… 爸爸，谢谢你！【篇二】 我们已经来奥兰多第四天了，是我们离开奥兰多前往华盛顿的时
候了。在奥兰多的日子里我结实了许多朋友。寄宿家庭的“爸爸妈妈”和四个可爱的“弟弟妹妹”还有美国小学的小伙伴们，可是我最不舍得的是你，我们的导游Halen。 在这四天的日子你留给我的是无数欢乐和感动。那天在迪士尼我一个不留意把相机弄丢了，就在我焦头烂额准备独自寻找相机的时候。Halen——你，出现了，你先带我去了客户服务中心，但是没有找到，于是放弃你的游玩时间，陪我走大街穿小巷，把我去过的地方都找了个遍，最后我们只好再一次前往客户服务中心，没有想到居然真的找到了。你真是上帝派来帮助我的天使，不管最后有没有找到，我都要感谢你。 后来，我们一起逛超市…… 总之，我对你有千千万万的感激，说也说不完，写也写不尽，但是我还是要在这里，说一声谢谢，真的谢谢你，Halen。 Halen，谢谢你，你是我的天使。【篇三】 一天上午我们正在上着数学课。 老师正在讲一道数学题的时候，突然，我感到从鼻子流出什么？一看，原来是一滴鲜红鲜红的血，我先用左手蹭了蹭鼻子，但鼻血竟然又流了，真是的！我为了不耽误上课，接着我就给同桌说：“谢谢你，用你一点纸行吗？”同桌说：“行”，我找到了纸，把鼻子捏住，可是不起作用。 我又小声的：“你帮我给老师说一声我流鼻血了”，同桌爽快的答应了，说：“老师，骆仕俊流鼻血了”。快、快去厕所洗一洗吧！
四年级作文谢谢你，我的同学400字 四年级作文谢谢你，我的同学400字 在一个风和日丽的早晨，我背着书包高兴地来到学校。 一进校门，映入眼帘的就是那美丽的三角梅。三角梅像一个个小巧的铃铛挂在树上，让人觉得十分舒服。我继续向班级走去，看到了菊花姐姐和兰花姐姐正向我打招呼呢！ 来到班级，那悦耳、优美的读书声从教室里传来。我走进教室，拿起语文书，认真地读了起来。 邱老师从走廊来到班级，原本严肃的神情，听了我们的读书声，变得笑容满面。老师走进教室，给了我们一个美好的笑容。 “铃铃铃”上课铃响了，邱老师抱着一叠厚厚的考卷向我们走来，庄重严肃地说：“现在，我们要来进行一次单元考，加油，老师相信你们一定能够取得好成绩！”说完，老师就一组一组地发试卷了。 试卷发下来了，我正准备写姓名班级，才发现，我的水笔没水了。我急得像热锅上的蚂蚁，心里想：“这该怎么办啊，水笔没水就考不了试了。”我正在
烦恼时，坐在旁边的晓慧，似乎知道我在想什么，毫不犹豫地向我递来一支可擦水笔，微笑的说：“你先用吧，考完之后再还给我！”“谢谢你，晓慧，你真是我的救命恩人啊！”我感激地说。“不用谢，我们是朋友嘛，本来就该互相帮助！”晓慧说完，就埋头考试了。我也在认真审题、答卷了。 过了几天，成绩出来了，我考了97分，我高兴得一蹦三尺。 晓慧，我要谢谢你，是你让我懂了，什么是“赠人玫瑰，手有余香”。 福建厦门湖里区厦门市东渡第二小学四年级:陈丽阳 四年级作文谢谢你，我的同学400字 在一个风和日丽的早晨，我背着书包高兴地来到学校。 一进校门，映入眼帘的就是那美丽的三角梅。三角梅像一个个小巧的铃铛挂在树上，让人觉得十分舒服。我继续向班级走去，看到了菊花姐姐和兰花姐姐正向我打招呼呢！
一年级xx作文100字（六篇） 【篇一】 今天，我和爸爸妈妈去踏春，暖暖的春风吹在我的脸上，就像妈妈的手温柔地抚摸着我的脸。走着走着，我发现路两边的树干上都冒出了嫩嫩的小芽芽，成片成片的麦苗绿油油的，大地就像穿上了一件绿色的大衣，一排排麦苗排列的整整齐齐，就像小朋友们在做早操。 快看，一群小白羊在草地里，有的在吃草，有的在玩耍，还有两只小羊头抵着头在打架呢！好可爱呀！ 【篇二】 哗哗的大雨过去了，晴朗的天空又来了。天空出现了彩虹，雨后的空气比原来更清新了，雨后的花儿比原来更美丽了，雨后的草地更绿了，雨后的天空特别的蓝……雨后让我感觉到了万物变了样，比原来更美了。 我喜欢雨后！ 【篇三】 冬天像一位和蔼可亲的老奶奶，脸上总是带着幸福的微笑。她手里拿着一只大篮子，里面装满了洁白的雪花。老奶奶日夜不停地忙着给房屋、田野、大树穿上了一件件羽绒服。人们围上了围巾，穿上了厚厚的大棉袄，戴上了漂亮又可爱的帽子。小朋友都跑出来玩了：有的在打雪仗，有的在堆雪人，还有的在跟小狗一起赛跑……玩得开心 极了。 冬天，是个既好看又好玩的季节。我爱您，美丽的冬天！ 【篇四】 寒冷的冬天过去了，春姑娘悄悄的来到了我们身旁。春天在哪里呢？星期天，妈妈带我到山上找春天。一路上，我看见桃花红了，像春天的笑脸，朝着我们微笑。油菜花黄了，一阵微风吹来，花儿散发出阵阵清香，引来
了一只只勤劳的小蜜蜂它们不停地采着花粉。山涧的小溪哗哗哗的往下流，溪水清澈见底。几条小鱼在石头缝里，游来游去，好像在捉迷藏。小溪旁的柳树也发芽了，长长的柳枝垂到了溪水里，像少女的头发。 春天的景色多美呀！ 【篇五】 在回家的路上，我看见了日落。 太阳先是金黄的，慢慢的，太阳挂在了树上，真像大树结了一个大大的果实啊！一刹那，它的颜色从黄变成了红彤彤的脸，很红很红，好像见我在看她，脸刷刷地红了，说：“不要看我嘛！多不好意思啊！”阳光照在玻璃上，一闪一闪的，漂亮极了！转眼间，这害羞的小姑娘已经在山顶了，脸更红了，旁边是她扔的纱巾。短短的几十秒，她的大半边脸已经落下去，她说：“再见啊！明天见”渐渐地，她不见了，连旁边的纱巾也被她拿走了…… 【篇六】 刘老师带我们找春天，有的同学发现树枝软了，树梢绿了；有的同学发现松树长出了细小的绿针；有的同学发现向阳的地方小草发芽了……我在一棵不高的树上发现了淡粉色的圆球。刘老师告诉我那是花苞，我还会继续观察的。多么盼望花苞快点变成美丽的花瓣啊！ xx果真悄悄地回来了！我喜欢春天。 网络搜集整理，仅供参考
我会做家务500字作文：3篇 我会做家务500字作文篇一：以前喝的豆浆都是妈妈在市场买的，不知道豆浆是怎样做出来的，也没有想过要学做豆浆。但是今天，我学会了，喝起来比市场买的甜多了，香多了，心里很有成就感。 早上的时候，婶婶问我会不会打豆浆?想不想学打豆浆?诗诗姐姐会打豆浆，如果我想学的话，让诗诗姐姐教我，我连忙说好。 终于到了打豆浆的时候了，我兴奋地把诗诗姐姐叫来，让她教我打豆浆。准备的工具有：装豆浆的大杯子、黄豆、一双筷子、白沙糖，最后还有一样很重要的东西豆浆机。 首先，黄豆用水清干净，装进装豆浆的大杯子里，之后把豆浆机清理干净，把黄豆装进豆浆机里，盖上盖子，插上电源，大约20人分钟就可以了。就在等待的时候，把一勺白糖倒进装豆浆的杯子里，20分钟过去了，豆浆弄好了，把热腾腾的豆浆装进大杯子里搅拌均匀，一杯香甜的豆浆就出来了。 自己亲手做的豆浆果然很好喝，我学会了自己做豆浆，真开心! 我会做家务500字作文篇二：在寒假期间，我帮外婆做了一件家务事。 我在外婆家度寒假。有一天，外公外婆不在家。我做完作业，想起了在街上听到的大人们的议论声：“现在的孩子吃的好，穿的
好，都不爱劳动，个个像小公主、小王子一样!”我可不想做小公主，我也要学着帮外婆做些事。我想：“我能帮外婆做点什么事呢?”我开始四处寻找，忽然，目光落到了玻璃窗上，只见玻璃上有许多灰尘。于是，我决定擦玻璃。 首先，我准备好抹布、旧报纸，再用脸盆盛满水。一切准备就绪，我就开始擦玻璃。 我看着窗户上的灰尘，心想：这些灰尘，用干抹布、湿抹布擦都不行，用什么呢?我忽然看见了阳台上浇花的喷壶，何不先用喷壶喷喷水呢?说干就干，我双手紧握着喷壶，用力的喷向玻璃，玻璃上落满了水雾。一会儿，灰尘都湿透了，我就把抹布浸湿，拧干，在玻璃上一上一下按顺序擦。湿抹布擦完以后，灰尘虽然没有了，可玻璃上却留下了一道道水迹。我赶紧拿来报纸，全面认真地干擦一遍。干擦完之后，水迹就完全消失了。 玻璃终于被我擦得干干净净，看着自己的劳动成果，心里特别高兴。外婆回来后，看见屋里的玻璃，都被擦得干干净净，也表扬了我。 家务劳动虽是一件小事，却能够体现我们敬老爱老的思想。今后，我要做出更多敬老爱老的实际行动来! 我会做家务500字作文篇三：星期天早上，爸爸上班去了，妈妈出去买菜，我一个人呆在家里挺无聊，心想：我还从来没做过家务，今天学着做吧。 我先在水龙头下接了半盆水，把毛巾浸湿，再拧干，就开始擦了。先擦客厅的擦几，电视机电视柜，再擦饭厅的饭桌。然后，又把毛巾洗干净擦卧室，我把爸爸妈妈房间里的床头，床头柜，
四年级谢谢你的作文 感谢你的关怀，感谢你的帮助，感谢你对我做的一切……在这个充满感恩之心的节日里，让我对你说声谢谢。下面是四年级有关感谢的作文，欢迎参阅。 我们已经来奥兰多第四天了，是我们离开奥兰多前往华盛顿的时候了。在奥兰多的日 子里我结实了许多朋友。寄宿家庭的“爸爸妈妈”和四个可爱的“弟弟妹妹”还有美国小 学的小伙伴们，可是我最不舍得的是你，我们的导游Halen。 在这四天的日子你留给我的是无数欢乐和感动。那天在迪士尼我一个不留意把相机弄 丢了，就在我焦头烂额准备独自寻找相机的时候。Halen——你，出现了，你先带我去了 客户服务中心，但是没有找到，于是放弃你的游玩时间，陪我走大街穿小巷，把我去过的 地方都找了个遍，最后我们只好再一次前往客户服务中心，没有想到居然真的找到了。你 真是上帝派来帮助我的天使，不管最后有没有找到，我都要感谢你。 后来，我们一起逛超市…… 总之，我对你有千千万万的感激，说也说不完，写也写不尽，但是我还是要在这里， 说一声谢谢，真的谢谢你，Halen。 Halen，谢谢你，你是我的天使。 亲爱的奶奶，我要说声谢谢你，你为我做的实在太多太多了。 记得那一次，阳光明媚，我们走在上学路上。我迈着轻盈的步子同，哼着轻快的小调，不知不觉走了大老远。当我快要到校门口时，忽然想起：忘了带美术袋，这下完了。于是 我便跟奶奶讲，奶奶说：“你先进去，我去回家帮你拿，然后交给保安叔叔，让他给你。” 我走进校园。天，还是格外蓝，可我的心却怎么也放不下来，想：要是奶奶没送来， 那怎么办呀? 第一节课过去了，奶奶还没送来。 第二节课过去了，奶奶还是没送来。 第三节课下课了，我的心“怦——怦怦——怦怦怦——”地跳着，想起美术老师生气 的样子，我便害怕得发抖。 过了一会儿，一位同学从外面急匆匆地跑进来，说：“***，你的美术袋。” 我感动极了，心想：奶奶，谢谢您，这样长的路，您都坚持要把美术袋送来给我，实 在太谢谢您了。 奶奶，您为我做了那么多，我一直没有谢谢您。今天，就让我好好地说声谢谢您吧!
小动物作文100字 我家的小动物陈恺曦我家里有很多可爱的小动物，你看一只小猫，它是我们人类的好朋友，帮助我们抓老鼠，它最喜欢吃鱼了。 小狗也是我们的人类的好朋友，它帮助我们看门，它最喜欢吃肉了，一看见肉啊，口水滴滴的流。而在门口草地上市小马和小牛，它们最喜欢就是吃草了，绿绿的青草是它们的最爱。这些可爱的动物都是我们的朋友，大家一起爱护它们吧。 池塘里的小动物仲梓文我在花园里的池塘里看到了两只天鹅、三只鸭子。那两只天鹅浑身长着雪白的羽毛，黑黄相见的嘴巴，黑色的脚蹼，它们游到岸上突然朝我和妈妈扑过来，掐我们，把我和妈妈吓得赶紧往上跑；它们一会又游到岸上来吃草，吃了一会后就张开翅膀，伸长了脖子，咯咯地叫，好像吃饱了要跳舞的样子。 我还发现有一只陌生的鸟飞过来，它看起来像是一只幼小的鹤吧。 我家的小动物们胡逸尧我们家有许多小动物，有兔子、狗、仓鼠、乌龟、金鱼。我们家的兔子是去年买的，买回来的时候只有我掌心这么大，现在已经有十斤了！然后是狗，狗已经听得懂命令了。还有仓鼠，今天我爸爸给它洗澡，洗完以后，它头上一点毛都翘起来了。乌龟嘛，它吃食的时候把嘴巴张的大大的，差点咬到我妈妈的手。金鱼在荷叶间游泳，有红的、黑的、白的、金的还有花的，金鱼的尾巴像剪刀一样，还有像丝带一样。 我们家的小动物可爱极了！ 我最喜欢的小动物朱俊林我最喜欢的小动物是小狗，有一次大姨送给我一只西施狗。我非常喜欢它，给它取名叫“史努比”。它有一双又黑又亮的眼睛，它的毛是三色的，尾巴翘翘的，很好看。 它给我带来了许多快乐，它不仅不吵不叫，还会照顾我不让别的小朋友欺负我。可是妈妈却把它送人了，因为妈妈怕影响到我的学习和健康，“史努比”走后我很伤心，每当我看见别人家的小狗时我就会想起它，我盼望我快点长大，再自己重新养一条和史努比一样的小狗。 小动物们的聚会解付义薄风和日丽的一天，小动物们都到池塘边来玩耍了，有长得色彩斑斓的小公鸡，有蹦蹦跳跳专为庄稼除害虫的小青蛙，还有整天飞来飞去忙忙碌碌的小蜜蜂，他们在一起谈论着，说这里的景色可真美呀！小公鸡说岸边有绿油油的青草，小青蛙说清澈见底的湖面飘着像盘子一样的荷叶，蜜蜂说到处都开着红艳艳的鲜花。 这时小公鸡说咱们也叫其他的小动物们来这里一起玩吧！大家齐声说好。然后小公鸡就喔喔喔大声的叫了起来。 我喜欢的一种小动物我家曾经养过一只小兔子，小兔子的耳朵长长的，而且小兔子的耳朵上的毛特别特别的柔软，让人摸了小兔子的耳朵就感觉特别的舒服。小兔子的耳朵里面还有一条粉色的竖线。 小兔子的头圆圆的，真像一个长满白色的毛的小皮球，小皮球可以摸，摸了之后很舒服！小兔子的眼睛是红色的，在我小的时候，我还以为小兔子的眼睛流血了。我一见小兔子我就向爷爷要一张纸，去擦小兔子的眼睛。可是小兔子跑得太快了，我连追都没有追上！。
作文网小编为你精选的作文： 记叙文 | 议论文 | 说明文 | 应用文 | 散文 | 美文 每个人都有着难忘的第一次，而我难忘的就是第一次做家务。下面是由小编为大家整理的“第一次做家务500字作文”欢迎阅读，仅供参考，希望对你有所帮助。 篇一：第一次做家务500字作文 每个人都经历过许多的事情，开心的，烦恼的，难忘的…… 在我经历的事情中，就像天上的繁星时时闪耀在我心头，伴我度过每一个快乐的日子。在这些事情中，让我对我印象最深刻的是我在读一年级的时候。 那是一个星期天，吃完了中午饭，妈妈对我说：“孩子，你能帮妈妈扫一次地吗？”我一听是扫地，我高兴得跳了起来，因为我早就想帮妈妈做家务了，再说扫地太简单了，就爽快的答应了妈妈。 我拿来扫把，开始在客厅里扫，我拿起扫帚扫过去扫过来，不知扫了多久，发现把这里扫干净了，其它地方脏了，把其它地方扫干净了，另外的地方又脏了，扫得我汗流浃背，不知怎么回事？这是妈妈走了过来笑眯眯地说：“孩子，像你这样扫地是扫不干净的。”“不就是扫过去扫过来嘛！”我还很不服气的说。“来，我教你，要从房间的四周往中间扫，不能把扫帚扬得太高，不能用太大的力，要不然你扫这里的时候会把灰尘扫到其它地方，扫其它地方的时候同样如此。”妈妈耐心的说道。 我听了还很不耐烦的样子，扫地还有那么多的讲究？我半信半疑地按照妈妈说的方法去扫，结果真的把房间扫得干干净净的，而且一点儿也不累。妈妈看了我的成果，开心地笑了，还连声夸奖我是一个聪明的孩子。我为能帮妈妈做好家务感到开心。 从这一次扫地，让我明白一个道理：做任何事情都要讲究方法，讲究技巧，只有这样，做每一件事情才能成功。 篇二：第一次做家务500字作文 从小到大，我一直是家里的小公主，从来不干家务活。可是今天，我长大了，所以，我决定做家务。 一个阳光灿烂的星期天，我刚从床上爬起来，就闻到被子里有一股汗骚味，妈妈说了，被套盖久了不洗就会发臭。我却很高兴，因为我有活干了。 我先把棉被套取下，那被套可真难取，要拉这边取那边的。我以前也见过妈妈洗被套，我便学着妈妈的样子，把被套放进洗澡盆里，装上一盆清水，然后打着赤脚踩进盆里。哎呀，这水可真凉！凉得我有从盆里跳出来。不过我觉得这也挺有意思的，于是再踏了进去。我扶着墙壁，像踩脚踏车似的踩被套。这被套真有趣，我踩左边，它右边就会鼓起一个包；我踩
谢谢你老师四年级作文400字 导读：本文谢谢你老师四年级作文400字，仅供参考，如果觉得很不错，欢迎点评和分享。 【篇一】 鲜花感恩雨露，因为雨露滋润它成长；苍鹰感恩蓝天，因为蓝天让它翱翔；高山感恩大地，因为大地让它高耸；……我感恩，很多人，我要感恩我们的叶老师。 记得我们刚进学校时，一切都是那么陌生，看见老师，心里是那么忐忑不安，就像羚羊看见猎人。但是叶老师对我们这些刚进校的孩子特别温和。您温和的语气，透露出对我们的喜爱，我们的心里一下子踏实起来，有什么事情也总是愿意和您说一说，您就像我们的知心朋友。 在生活中会关心我们，在学习上也会帮助我们，您的爱，太阳一般温暖，清泉一般甘甜。您的爱，比父爱更祥和。您讲的课，是那样丰富多采，每一个章节都仿佛在我面前打开了一扇心灵的窗户，让我看到了一个五彩斑斓的世界。每次校运会，总是看见你为起跑大声的发出号令，嗓子嘶哑了，仍坚持为校运会忙着。 您关心着我们班的每一位同学，作为学生的我们，最要感恩的就是老师，老师教了我们许多丰富多彩的知识，您像那默默无闻的树根，使小树茁壮成长，又使树枝上挂满丰硕的果实，却并不要求任何报偿。您给了我们一杆生活的尺，让我们自己天天去丈量；让我们处处有学
习的榜样。 是谁把雨露撒遍大地？是谁把幼苗辛勤哺育？是您，老师，您是一位伟大的园丁！看这遍地怒放的花朵，哪一朵上没有您的心血和您的汗水，哪一朵上没有您的笑意！老师，我感谢您！老师，我感谢您，看着您在黑板上留下的一行行整齐而漂亮的字迹，我能掂量出这中间蕴藏着多少的奥妙和辛勤的汗水！ 【篇二】 老师，您好！这六年来，我们这些“猴子们”让您添了不少苦，我真想说："谢谢您，老师”和您相处的每一天，我仍历历在目。 曾对您存有不满，曾对您怀有怨气；但我也曾对您存有爱慕，怀有敬佩。无论曾几何时，我曾做什么，都不曾改变，我对您的爱。老师，谢谢您！ 当年，刚上五年级的我还是一个不懂事的孩子，面对一只只陌生老师的面孔，我很害怕。但是，您用和蔼感化了我们，一直暖到了我的心田。那时我真想说：“谢谢您，老师。” 我不知道我跟您一起携手走过了多少天，但我深知：一年三百六十五天，正是三百六十五颗为我们而操劳的心。我不知道我在您心中的地位如何 但我深知：天有多高，您就有多高；宇宙有多大，您就有多大。 说起地位，我想起了一件既令我难堪又让我开心的事。 那天，我已经是xx年级的学生了。那面孔不再陌生，变得格外亲切。在那节语文课，我很幸运被选为组长。老师您让组长们把练习
我喜欢春天一年级作文100字范文10篇 春天来了，天气变的暖洋洋的，小草偷偷地从土里钻出来，大地一片新绿，各种各样 的花儿也开放了，有粉红的桃花、雪白的梨花、黄灿灿的迎春花……小燕子从南方飞回来了，冬眠的动物也苏醒过来了，人们再也不用穿着厚厚的棉衣了，小朋友们已经开始放风筝了。 “一年之计在于春”，春天真是一个美好的季节，我喜欢春天! 阳光明媚的上午，老师带我们去公园观察春天到底有什么变化。突然，我和同学们都 听到“嗡嗡、嗡嗡”的声音，我们四处寻找，看到一只蜜蜂围着一个盒子转，我们都很好奇，凑近一看原来盒子里有好多花瓣，小蜜蜂在采蜜啊!老师告诉我们，春天来了，小蜜蜂多 勤劳，我们要向小蜜蜂学习，做个勤劳的好孩子。 今天我去郊外了，我发现一排排的树上发出了嫩绿的叶子。 春天来了，小草从地地下钻了出来，嫩嫩的绿芽。流动的小溪好像在说：“我要去郊 游了。” 我喜欢春天，春风刮在脸上感觉好极了。 春天来啦!春天的变化可大了! 我脱掉棉袄，和爸爸妈妈去找春天。 化了冰的小溪丁丁冬冬唱着好听的歌，柳树长出了嫩绿的芽，动物们都出来活动了……放风筝的人可真多呀!春风用手轻轻地托着风筝，在天空中跳舞，小鸟们叽叽喳喳地 叫着，好像在说：“春天来啦!” 我觉得春天是一个多彩的季节。 在春天之前，树木不像夏天那样茂盛，远处的鸟儿渐渐变少了。可是春天，鸟儿变多了，树木发芽了。
在冬天时，雪花慢慢地落下来，像给大地穿上厚厚的毛衣。春天，雪花漫漫地融化了，天气慢慢地暖和了，融化在雪水的小溪浸在太阳公公的怀抱里。春天，树木又长了一岁， 所以树木的年轮又多了一圈。小松鼠的松果吃光了，青蛙跳出来了。 春天的变化可真多，让我们一起去发现春天的变化! 春天到了，大自然正在慢慢变化。 春天田野里的小草像一根根针一样插在泥土里，田野里的油菜花金黄金黄的，大树的 叶子像一只只小船。 春天公园里的小花五颜六色的，远远望去像一片灿烂的朝霞，公园里的柳树发芽了， 柳树上的柳条长长的像小姑娘的头发。 燕子飞回来了在2上叽叽喳喳的唱歌，冬眠的小动物都醒过来了，小松鼠在和小猴子 比赛爬树。 果园里农民伯伯种的树都发芽了，开出美丽的花朵。 人们脱掉棉衣换上漂亮的春装。 春天的变化真大呀! 每天上学时，我都发现春天的变化。 今天，我发现树木们都长出了一些小叶子，小花们张开了笑脸，小草从泥土里探出了 小脑袋，小溪唱着欢快的歌曲，动听极了!我们也发生了变化，我们的衣服穿少了，裤子 也穿薄了。 啊!春天真美，我喜欢这美丽的春天! 风，吹绿了树的枝条;水，漂白了鸭的羽毛。盼望了整整一个冬天，你看春天已经来到。 南湖公园又开始那么的热闹，这天，我去南湖放风筝，蔚蓝色的天空中飘着几朵雪白 的云朵，还有好几十只风筝飞舞在天空中，五颜六色，美丽极了! 树木已经开始变成浅绿色，小河里的水叮叮咚咚，那是春天的琴声吧。可爱的小花可 能早想开放，你看，朵朵盛开的樱花多么迷人漂亮。
为父母做家务心得感想作文500字_做家务心得体会作文 劳动有利于调节我们的大脑，让大脑得到休息。劳动有利于我们心灵手巧，提高 我们的创新能力。大家平时帮父母做家务有什么心得体会呢?以下是小编为大家准备的为父母做家务心得感想作文，欢迎大家前来参阅。 为父母做家务心得1 每天妈妈起早贪黑的上班，还要接送我和妹妹，真是很辛苦呀!今天晚上妈妈下班 回来，给我们烧的都是我和妹妹爱吃的菜，我和妹妹吃的津津有味。吃好了饭，我和 妈妈说：“让我来洗碗吧!你出去放松放松。”妈妈和爸爸去散步了。 我和妹妹开始行动起来。我先在水槽里放满了水，再把碗和筷子统统放进水槽里，在洗碗球上滴一些洗洁精，擦洗一遍。一旁的妹妹就在那里玩，我把水龙头打开，把 碗里放满水，里面的泡泡可遭了殃，手放碗里搅拌，泡泡一个个地爆炸了。我愤怒地说：“我辛辛苦苦地洗碗，你竟然在旁边玩!”妹妹委屈地说：“哥哥我现在不玩了，我们 俩一起好好的洗碗。” 妹妹吸取了教训，开始好好洗碗。我和妹妹一个人拿一个碗。我的碗就像一个调 皮的小毛孩，一下子从我的手里溜走了，掉进了水槽里，溅我一身水。一旁的妹妹偷 偷地嘲笑我，结果她自己的碗也掉进了水槽里，溅到了自己的脸上。我说妹妹你还笑 不笑了!”我们把水倒掉，再接一槽水，在里面清洗。碗里冲一冲，碗底冲一冲。不一 会儿，我们俩把碗和筷子洗得干干净净。 妈妈回来了，看见我们把碗洗的干干净净，用微笑的面孔表扬了我们，妈妈说：“你们真是妈妈的宝贝，是个乖巧懂事的好孩子。”
为父母做家务心得2 今天是星期天，我睡了个懒觉，九点钟才起来。下床一看，发现爸爸妈妈都出去了。吃完父母留给我的早餐后，望着脏兮兮的屋子，决定抓住这个机会锻炼一下自己。 我看了看灰尘很多的房间，准备先打扫房间。我拿来扫帚和撮箕，装着很在行的 样子，一甩一甩的，把灰尘都扬起来了。我呛得受不了，连忙打开窗户，灰尘全部随 着风飘出去了。 我又拿来拖把，把它弄得湿漉漉的，我专心致志地拖起来。因为地面太滑，我一 个踉跄，摔了个“狗啃泥”。过了一个小时，我坐在沙发上欣赏我的“杰作”：地板被打扫 的一尘不染，还闪着光呢。 这时，时钟已经指向了十一点，我肚子饿得咕咕叫，该煮饭了。我先淘米，把米 和水混在一起，不停地用手搅拌。淘干净后在电饭煲内放好水，插上插头，按上按钮。然后我从冰箱里拿出豆角，洗干净后，小心翼翼的切好放到锅里。我又往锅里倒了点 油和盐，炒起来。炒完豆角，我看了时间，急忙三步并两步跑到电饭煲旁，拔掉插头，慢慢的揭开锅盖，长出一口气，说：“还好没焦!” 等我做完菜，爸爸妈妈也回来了，他们看见我收拾好的房间，和桌子上的饭菜， 不停地说：“我们儿子长大了!”“哈哈哈……”全家沉浸在笑声当中。 这个星期天我做了一些力所能及的家务活，既能减轻父母的负担，又锻炼了我的 生活自理能力。做家务的感觉真好! 为父母做家务心得3 小时候，我们看着爸爸、妈妈在家里做家务活。那时，我又怎么会知道做家务是 如此不易啊! 有一天，我对爸爸、妈妈说道：“今天，由我来帮你们做家务吧!”爸爸、妈妈欣慰 地看着我，笑着说：“我们的儿子长大了。”首先我从客厅开始搞卫生。我拿起扫把把 客厅里的地扫干净，然后又用抹布把地板擦得一尘不染。 换过新的水之后，我又把桌子擦了一遍，那叫一个亮啊!搞完客厅，现在该打扫房 间以及阳台和厨房了。我心里想：天啊!光打扫一个客厅都这么费劲，想想爸爸、妈妈 是有多么不容易啊。
勤劳的小蜜蜂作文范文参考 篇一：勤劳的小蜜蜂 蜜蜂们住在一座花园附近，它们每天早上飞出去，晚上飞回家，采回甜甜的 蜜给人吃。 花园里长着五颜六色的花，草也青青的，空气很新鲜。可是最近天旱了，花 草也快死了，蜜蜂们很着急。 这时， 一只最小的蜜蜂想了一个办法， 它找来一个水桶， 从河里提水去浇花， 一天浇好几次，不怕累也不怕苦，花慢慢地又长高了。 其它的蜜蜂看见了， 都夸小蜜蜂勤劳。 它们也像小蜜蜂学习， 每天早早出去， 晚晚的回家，采回了很多的蜜给人吃。 篇二：勤劳的蜜蜂 清晨，我站在阳台边上背唐诗，突然，一只小蜜蜂飞了过来，我曾经在一本 书上看到这样的一个消息:蜜蜂的后面有一根针，当你惹怒了它的时候，它就会 用它的这根针，来咬你，你的身上会起一个大包的，蜜蜂身上的针，连着它的内 脏， 它攻击你， 是自杀式的攻击， 一只蜜蜂攻击你后， 会有许多只蜜蜂来攻击你。 所以，我生怕惹怒了它。谁知道，这只蜜蜂居然看中了我养得这些太阳花，赖在 花丛中间不走了。唉…… 这个时候，妈妈走了过来，她看到这里有一个蜜蜂，莞尔一笑说:“放心地 背书吧!它不会叮咬你的。只要你不打它，不驱赶它，它是不会伤害你的。你看! 它多么勤劳，这么早就起来了，它的腿上已经有很多花粉了，说明，它在我们起 来之前就起来了。这里不是还有两只勤劳的大‘蜜蜂’吗?”我看了半天，也没 有发现第二只蜜蜂。 我不再理会，继续背诗……我突然明白了:妈妈说得那两只勤劳的大蜜蜂就 是我和妈妈，妈妈早起洗衣服，我早起背书。的确是两只勤劳的大“蜜蜂”啊! 篇三：勤劳的小蜜蜂 有一天，一只小蜜蜂出去采蜜。它飞到一朵花上刚要开始采花粉，忽然，天 上响起了阵阵春雷。轰隆隆的雷声把小蜜蜂吓了一跳，它知道要下雨了，于是马 上飞回家里躲雨。不一会儿，雨停了，太阳出来了，一条彩虹挂在了天空。勤劳 的小蜜蜂又出去采花蜜了。 篇四：勤劳的小蜜蜂
1/6
作文500字：通过做家务我学到了 虽然说，帮妈妈做家务很累，但是从劳累当中学到了许多有用的东西，还是值得的。下面是WTT为您推荐的作文：有一天，爸爸异想天开，叫我当一次星期日的“值日家长”，妈妈举双手赞成，猫咪也连叫几声：“喵喵喵(妙)”真是有趣，班级里有值日班长，公司里有值日经理……还从来没听说过什么“值日家长”。虽说是个新鲜事儿，但我还没有思想准备。 早上六点闹钟一响，我一骨碌爬起来，赶到厨房给要上班的父母做早饭。早饭虽然简单，却把我累出了一身汗：香肠切得像线轴，倒牛奶弄湿了衣袖。 真不容易啊!早饭总算端上了桌。我学着妈妈的口气向还在呼呼大睡的爸爸嚷道：“快起来!快起来!你又要和猫咪并肩比懒 了!”妈妈把手放在嘴边“嘘”了一声，“你爸爸昨天晚上到11点才睡的。”我吐了吐舌头，不敢再打扰他老人家。 饭桌上，我抱歉地说：“对不起，我把盐错当糖放在牛奶里了。”“没关系，我早就腻歪甜牛奶了，总想改成咸牛奶，就是老忘。”“哈哈哈……”爸爸可真逗! 作为“家长”，我有权利请人做事。妈妈精通家务，我叫她帮我洗衣服，爸爸力气大，我让他换煤气。令我庆幸的是，他们都绝对服从。
晚上，我发表了卸任演说：“本值日家长初次上任，有很多失误之处，请多多包涵!妈妈处处配合我表扬;爸爸工作认真表扬;猫咪打碎饭碗该罚!” 当“值日家长”让我对爸妈的辛劳有了初步体验，也让我懂得了珍惜别人的劳动成果，理解万岁!感谢家人! 同学们，当你们坐在一尘不染的沙发上，躺在干干净净的床上，靠在洁白无暇的墙壁上……你可曾想过，别人要花多少时间和精力来把它打扫得这么干净?今天，我体验了做家务的辛苦，我深深地感受到了我们要注意家里的卫生，不乱丢乱扔垃圾。 一大清早，我拿好了卫生工具，整装待发。我先要打扫卧室，卧铺好了被褥，把毯子折叠好，拉开移门，把毯子放入衣柜里。把床上的灰尘掸到地上。然后用扫把把卧室里的垃圾清扫掉，扫地时要特别注意一些很难扫的卫生死角，比如：门的背后、床头柜两侧、床头柜下面、床的下面都要扫的干干净净、一尘不染。然后再用拖把拖一拖，卧室的卫生就打扫好了。 接着要打扫卫生间，你别看卫生间小，可是打扫起来保证把你累得满头大汗。我先用是的抹布把镜子擦得光彩照人、锃光瓦亮。然后我用平底的拖把把墙壁、玻璃移门上的灰尘都擦掉，然后再把洗手盆上的牙膏、污渍……擦干净。最后再扫一扫地砖，大功就告成了! 接下来我去挑战卫生难点厨房。厨房打扫起来可麻烦了!我先把碗洗干净，放入消毒柜里，再用湿的抹布把台面擦干净，再把
谢谢你帮助我 一个阳光灿烂的星期六，我和妈妈去大润发买一些生活必需品。回家的路上发生了一件令我难忘的事。 为了节省一点时间，妈妈骑电动车选择了一段逆行的路，但是后来她为此付出了惨痛的代价。因为害怕，妈妈的手有些抖，当她看到一个可以通到人行道的小坡时，便迫不及待地想拐到上边去。忙中出错，不知道那里为什么会有水，瞬间我们和车子一起倒在了地上，我手中拿的饮料顿时洒了满地，我的脚跟一阵剧烈的疼痛，泪水夺眶而出，我痛苦地趴在地上，手里还紧紧攥着空的饮料杯，望着这个突然颠倒的世界，我嚎啕大哭。 这时，对面来了一个戴着墨镜，皮肤黝黑的胖叔叔，他看到我们立刻停住了脚步，赶紧蹲下来，关切地问我：“小朋友，你没事吧？”大概因为太疼了，根本无心回答叔叔的问话。他一边说一边帮不知所措的妈妈把车抬了起来，让我的脚脱离了电动车的魔掌，更神奇的是他从包里拿出了一个棒棒糖笑着递给我，说：“小朋友，我这里有止痛棒棒糖，要不要来一个？”我看了看叔叔，破涕为笑，毕竟棒棒糖对我的吸引力还是巨大的，我的疼痛瞬时随着棒棒糖飞到了九霄云外，连忙点头说：“我要！我要！”与此同时，刚刚缓过神来的妈妈也连声向叔叔道谢，胖叔叔见我没什么大事，便准备起身离开，临走时，他又千叮万嘱让妈妈一定带我去医院检查，以后骑车不要逆行，望着他远去的背影，我突然想起了什么，大喊一声：“叔叔，谢谢你！”逆着阳光，我依稀看见他那张黝黑的带着微笑的脸向我点了点头，泪水再
次湿了我的眼睛，这次是感动的泪水。 回家的路上，我和妈妈一直回味着那温暖的一幕。那双手在我万分窘迫的时候将我扶起，那话语犹如灿烂阳光照进我心里。叔叔，谢谢你！帮助我！
小学生小蜜蜂作文10篇 导读：小学生小蜜蜂作文1 上课铃响了，同学们迅速地冲进教室。我们正聚精会神地听老师讲课。忽然，一只可爱的小蜜蜂“嗡嗡嗡……”地闯进来，在空中盘旋，大家惊慌失措。这时，有一些女生都差点叫了起来，男生的胆子特别大，竟然伸出了手，想打死蜜蜂。小蜜蜂可真机灵，一会飞到东，一会儿飞到西，好像在对我们说：“怎么样，还想来打我吗？”这时，老师对我们说：“别管它，我们不打它，它也不会用毒针蜇我们。”我想起了妈妈说过：蜜蜂是益虫，没有了它，也就酿不出我最爱喝的蜜了。 我们连忙收回了手。小蜜蜂扇动着翅膀，在教室里飞了一圈，我心想：“小蜜蜂为什么会飞进来呢？不会也想上一节语文课吧！它的妈妈找不到它，该多着急呀！”我真想对它说：快点回家吧！快去采蜜吧！别再打扰我们，去为人民做贡献吧！可小蜜蜂还在飞，我们索性不管它了，又开始认认真真地听课。 过了一会儿，小蜜蜂好像知道了什么，急急忙忙地飞出了明亮的教室。这时，教室又恢复了平静，我们又开始专心致志地听课。 小学生小蜜蜂作文2 蜜蜂们住在一座花园附近，它们每天早上飞出去，晚上飞回家，采回甜甜的蜜给人吃。 花园里长着五颜六色的花，草也青青的，空气很新鲜。可是最近天旱了，花草也快死了，蜜蜂们很着急。
这时，一只最小的蜜蜂想了一个办法，它找来一个水桶，从河里提水去浇花，一天浇好几次，不怕累也不怕苦，花慢慢地又长高了。 其它的蜜蜂看见了，都夸小蜜蜂勤劳。它们也像小蜜蜂学习，每天早早出去，晚晚的回家，采回了很多的蜜给人吃。 小学生小蜜蜂作文3 春暖花开，万物复苏。在万紫千红的花丛中闪过那细小的身影。“嗡嗡嗡”，“嗡嗡嗡”，勤劳的小蜜蜂飞来飞去地采花粉。如此细小的身躯中却隐藏了一种伟大的精神——勤劳，坚持。 太阳高挂，我们可能还在床上睡懒觉，可小蜜蜂却早早地起了床，飞到花丛中，开始她忙碌而又辛苦的一天。她停在花上采蜜，一朵又一朵，她从不偷懒，也没有丝毫怠慢之情，她的额角挂满汗珠，可是她也不休息，继续飞来飞去。她飞了一程又一程，采了一朵又一朵花，她一直坚持着做她的工作——采蜜。 多么伟大的小东西！她勤劳、执者，从每朵小花里采一点蜜，或许，几十朵花中的蜜都不足以完成她的任务，可这小东西却依然坚持做着，始终没有松懈过，那是因为她懂得一个道理，而且一直在实践这个道理：世上无难事，只怕有心人。这个道理人人都懂，可是，我想问一句，古往今来又有几个人能够真正去实践他、坚守他呢？ 让我们向蜜蜂学习，让我们去歌颂她，记住她——那小小的蜜蜂。 作为一个学生，我们应当向蜜蜂一样，从书本中汲取知识，在知识的海洋里找到启航灯，找到做人的道理。只要坚持不懈，只要执着认真，就能为自己开辟出一片崭新的天地。
篇一：做家务劳动 今天早晨，我正在写作业，看见妈妈端着一大堆穿脏的衣服，要进来洗衣服。 我跑过来，对妈妈说：“妈妈，现在还很早呢，您先去休息，我来帮您洗吧!”妈妈听了，笑眯眯地说：“好，好。不过要洗干净，我要来检查的哦!”我点点头，站在一个小凳子上，然后把洗衣粉倒在衣服上，卖力地洗起衣服来。虽然洗得都快晒成烤“猴”了，但我帮妈妈分担了家务活，心里甜滋滋的。 我正准备去喝点水，但妈妈又打算要拖地。我马上跑了过去，对妈妈说：“妈妈，不是叫您去休息吗，怎么又跑这来了?快去休息，让我来帮您拖地。”妈妈听了笑眯眯地说：“咱家的宝贝长大了，都能帮妈妈干活了。”等妈妈说完这句话，我立刻从妈妈手里把拖把拿了过来。”首先，我先把拖把拿到池子里洗干净，然后，从屋子里面往外拖，这样就可以把扫地时没有扫干净的脏东西一并拖出来。当我拖到厨房时，看见有一个小黑点粘在地上时，我又是用拖把拖，又是用手抠，费了好大的力气才把小黑点擦掉。我高兴地手舞足蹈。 把地板拖干净以后，我又跑到厨房，想把我们早餐吃好的碗洗干净。我把碗一个一个拿来用水冲洗，很快就只剩一个碗了。我拿起它搓了又洗，洗了又搓;可是我笨手笨脚的，一不小心，这个滑溜溜的碗就从我的手里“逃”了出去，打碎了。妈妈听到这个声音，连忙赶来厨房，看到地上破碎的碗，把我拉到房间里着实得教训了一顿。 今天真悲哀! 篇二：做家务劳动 没一个家庭，都会有妈妈为我们忙碌着。几乎家里面所有大大小小的家务事，总是由妈妈来料理，妈妈为整个家做出了很大的贡献。那么，作为一名中学生，我们也应该为妈妈分担一些家务呀! 一个周末，我放假在家，做完作业后，准备休息一下，这时，我觉得家里很脏了。妈妈平时上班，没有什么时间搞卫生。这次，趁妈妈休息时，我帮妈妈做了一些家务事。 一开始，我先将地板扫干净。拿起扫把和簸箕，我弯下腰，把家里里里外外、仔仔细细地扫了一遍，一个角落也没有疏忽。接着，我将拖把打湿了，然后把地板拖了一遍。这时候的地面光滑又闪亮，就像一面没有任何灰尘的镜子。最后，我把家里的一些零碎的东西都收拾好，把沙发上的坐垫摆平整。看上去，家里焕然一新，显得格外温馨。 当我坐下休息时，才感到累，手脚酸胀。我想，妈妈几乎天天都有搞卫生，但我从来没有听到妈妈说过累。妈妈默默地为我们服务着，可我平时竟没想到妈妈是这样的累，我从没有替妈妈帮过忙，只是在家里撒着娇，天天享受着…… 自从那次帮助妈妈做家务事之后，我懂得了妈妈的辛苦、妈妈的累。我便在心里暗暗地下了决心：要努力学习，以后能够从事一门好的职业，回报妈妈为我的付出。 妈妈，您为了我们作了很大的付出，我会以我的实际行动去报答您的! 篇三：做家务劳动 一天，我在家里非常无聊，不能看电视也不能上网玩游戏，因为妈妈说怕把眼睛弄近视了。我不知道该干什么好。于是，我低头看了看客厅的地板，地板上有很多黑黑的脚印和一层厚厚的灰尘，我想：肯定是妈妈很长时间没有拖地扫地了。平时妈妈上班那么累，而且我还在地上扔一些果皮纸屑，不如，我就帮妈妈做一次家务吧! 说做就做。我先拿着扫帚和撮子，用扫帚把地上的果皮纸屑扫进撮子里，然后把垃圾倒掉，就开始拖地了。我先拿了一个桶，然后拧开水龙头，把里面接一半水，再用拖把沾一点水，把水沥干。我拿着拖把来到客厅，刚想开始拖地，就想起妈妈拖地时对我说的话：拖地时要右手向下左手向上的拿着拖把，要不然，地就拖不干净。我先把拖鞋底弄干净，然后按妈妈的方法拿拖把，从门旁边开始拖。我拖了一遍觉得很累，而且地也没有拖干净，就产生了想放弃的念头，我心想：要是我放弃了，不就是半途而废吗?